# Message Expiration

> Stale messages are worse than no messages — set a TTL and let them die.

- **Category**: Integration
- **Subcategory**: Message Construction
- **Canonical URL**: https://designpattern.fyi/patterns/message_expiration/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
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.





## Trade-offs


### 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




### Considerations & Drawbacks

- 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







---
**Reference**: [Original Source](https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageExpiration.html)