We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Messaging Event Systems
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Messaging Event Systems
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A grocery store mails you a coupon: "20% off, valid through Friday." You find it in your mailbox on Saturday. It's worthless. The offer was time-sensitive. It only made sense within a window.
Messages work the same way. A "flash sale starting NOW" notification sent to a queue is useless if the consumer doesn't process it until three hours later, after the sale ended. A price quote is meaningless after the market closes. A ride request is irrelevant if the rider gave up waiting 10 minutes ago.
Message expiration, also called TTL (Time-To-Live), attaches a timestamp or duration to a message. If the message isn't consumed before the TTL expires, it's automatically discarded or routed to a . This prevents stale, irrelevant messages from clogging your system and wasting consumer resources.
can be set at two levels:
Per-message TTL. Each message carries its own expiration time. A flash sale notification might have a 5-minute TTL. A daily report trigger might have a 24-hour TTL. An OTP verification code: 10 minutes.
Per-queue TTL. The queue itself has a default TTL that applies to all messages. Every message in this queue expires after the configured duration unless it has its own per-message TTL that overrides it.
Message: {
body: "Flash sale: 50% off!",
expiration: 300000 // 5 minutes in ms
}
Queue: {
name: "notifications",
messageTtl: 86400000 // 24 hours default
}
What happens to expired messages:
| System | Default Behavior | Dead Letter Support | TTL granularity |
|---|---|---|---|
| RabbitMQ | Silently discarded or routed to DLX | Yes (Dead Letter Exchange) | Per-message + per-queue |
| Amazon SQS | Deleted after retention period (1-14 days) | Yes (DLQ configuration) | Per-queue only (MessageRetentionPeriod) |
| Deleted by log retention policy | No native DLQ | Per-topic (retention.ms) | |
| Azure Service Bus | Expired messages go to DLQ | Yes (built-in) | Per-message + per-queue |
| Google Pub/Sub | Acknowledged or expired after retention (7 days default) | Yes (dead letter topic) | Per-subscription |
The important nuance: in RabbitMQ, expired messages are only removed from the head of the queue. A message in the middle might be logically expired but won't be physically removed until it reaches the head. This means per-message TTL with varying durations can behave unexpectedly. If a 1-hour TTL message sits behind a 24-hour TTL message, the shorter one stays in the queue until the longer one is consumed or expires. Kafka avoids this entirely because it uses segment-based retention: entire log segments are deleted when the oldest message exceeds retention.ms.