 |
My application is using Messaging. If a Message’s data or request is not received by a certain time, it is useless and should be ignored.
How can a sender indicate when a message should be considered stale and thus shouldn’t be processed?
Set the Message Expiration to specify a time limit how long the message is viable.
Once the time for which a message is viable passes, and the message still has not been consumed, then the message will expire. The messaging system’s consumers will ignore an expired message; they treat the message as if it where never sent in the first place. Most messaging system implementations reroute expired messages to the Dead Letter Channel, while others simply discard expired messages; this may be configurable.
A Message Expiration is like the expiration date on a carton of milk—after that date, you’re not supposed to drink the milk. If the expiration date passes while the milk is on the grocery store shelf, the grocer is supposed to pull the milk off the shelf and not sell it. If you end up with a carton on milk that expires, you’re supposed to pour it out. Likewise, when a message expires, the messaging system should no longer deliver it. If a receiver nevertheless receives a message but cannot process it before the expiration, the receiver should throw away the message.
... Read the entire pattern in the book Enterprise Integration Patterns
Example: Azure Service BusNEW
Azure Service Bus implements Message Expiration both at the entity and the message level. Messages expire at the earliest of the Message Expiration set in the message or the entity, e.g. the queue or topic. Expired messages are sent to a Dead Letter Channel if one is specified. Messages that are locked for delivery (see Transactional Client) won't expire as long as they are locked.
Example: Amazon EventBridgeNEW
Amazon EventBridge uses a built-in Message Expiration that can trigger on elapsed time or the number of failed delivery attempts, whichever comes first. The default values are 24 hours and 185 retries, but can be customized in the console or via the command-line by using the RetryPolicy setting of the EventBridge target:
"RetryPolicy": {
"MaximumRetryAttempts": integer,
"MaximumEventAgeInSeconds": integer
}
Asynchronous targets like SQS, SNS, or CloudWatch logs rarely trigger the Message Expiration because they can consume messages at the same rate as they arrive on the event bus. However, Message Expiration is an important setting when using rate-limited targets like API Destinations (HTTP calls).
Example: Google Cloud PubSubNEW
Publish-Subscribe Channels generally have longer Message Expiration as a new subscriber might be interested in messages that have already been consumed by existing subscribers. Google Cloud PubSub includes a message_retention_duration setting for both topics and subscriptions (see Publish-Subscribe Channel for an explanation of topics and subscriptions) that allows subscriptions to replay messages that predate the subscription, allowing subscriptions to act as Durable Subscribers. The maximum setting is a generous 31 days, but you pay for storage.
Related patterns:
Dead Letter Channel, Durable Subscriber, Guaranteed Delivery, Invalid Message Channel, Message, Messaging, Publish-Subscribe Channel, Request-Reply, Transactional Client
Integration Pattern Language
