Back to Catalog
Integration
Message Construction
Message Expiration
Stale messages are worse than no messages — set a TTL and let them die.
Intent & Description
Real-world Use Case
Ride-sharing — a DriverLocationUpdate message expires after 5 seconds. If the consumer is lagging, it skips 30-second-old location data rather than updating the map with stale positions. Users see accurate driver locations.
Source
📌 TL;DR
Message Expiration = give your messages a best-before date. Stale messages get auto-discarded. Essential for time-sensitive data like prices, positions, and availability.
Advantages
- Prevents processing of irrelevant or harmful stale data
- Reduces queue backlog — expired messages are automatically cleaned up
- Self-enforcing freshness guarantee without consumer-side logic
- Improves system efficiency by discarding what does not matter
Disadvantages
- Mis-set TTL discards valid messages (too short) or keeps stale ones (too long)
- Expired messages are silently dropped by default — needs monitoring
- Consumer must still handle “message arrived but data is stale” edge cases
- TTL is coarse — not suitable for complex time-window logic