SMS expiry: keeping obsolete notifications out of the delivery queue
Connect business-event freshness to SMS queues and provider validity periods with absolute deadlines, cancellation rules, bounded retries and useful delivery metrics.
Contents
A customer receives a dispatch notification after collecting the order. An authentication code arrives after it has expired because a queue resumed sending when connectivity returned. Transport delivery may succeed while the message has already lost its purpose. A notification therefore needs a useful lifetime that survives every handoff from the business event to the provider.
Define usefulness at the source
The process owner decides the deadline. A sign-in message depends on the code lifetime; a reminder depends on the appointment; an order update depends on subsequent state changes. One TTL for every notification conceals these differences.
Keep both the original event time and an absolute expiresAt. For example, if an event occurred at 10:00 and remains useful for ten minutes, a CRM delay until 10:04 must not move expiry to 10:14. The illustrative deadline remains 10:10. Actual intervals belong to the business policy.
Separate three different limits
Each stage controls a different part of the journey:
| Limit | What it controls |
|---|---|
| Business deadline | How long the notification remains useful |
| Queue retention | How long infrastructure preserves the job |
| Provider validity period | How long an accepted submission may await delivery |
Queue retention does not replace a freshness check. A provider validity setting does not recall a message already sent. Verify whether the selected route supports that setting, including its precision and minimum value, before relying on it.
Recheck before every submission
Persist the deadline with the job, for example through the transactional outbox pattern. When a worker reads the job, it checks the deadline and current event state before selecting a route.
Calculate the remaining lifetime immediately before calling the provider. If it cannot accommodate expected latency and API constraints, mark the job obsolete. Where supported, express that remaining interval in the provider’s validity format while preserving the original business deadline internally.
Retries must not restart the clock. After a timeout, first establish whether the earlier submission was accepted: submitting again may create a duplicate. The SMS route failover guide covers this uncertainty in more detail.
Cancel when the meaning changes
An order cancellation, rescheduled appointment or replacement code can invalidate a notification before its deadline. Link each job to a business-object ID and event version. A newer version can cancel an older job while it is still under your control.
Checking state and submitting to an external provider cannot form one atomic transaction. If the event changes after submission, recall cannot be guaranteed. Neutral wording that links to the current status can be more useful than promising unconditional cancellation.
Measure expiry separately from failure
Distinguish expired_before_submit, provider rejection and delivery after the useful deadline. These conditions have different causes and owners. Preserve a late delivery receipt for reconciliation without triggering another message.
For each notification class, measure job age before submission, cancelled and expired jobs, and delivery inside the useful window. A rising expiry rate can expose an overloaded queue, delayed source events or an unrealistic business deadline.
Exercise provider outages, long queues, rescheduled appointments and repeated callbacks. The system should discard obsolete work and record the reason. When integrating QuickTel, confirm route-specific validity controls; business freshness rules still belong to your integration.
