Designing reliable notification queues and retries

If your application calls an SMS or email provider directly while a user waits, a slow or failing provider slows down or breaks your application. The fix is to separate "decide to send" from "send".

Put messages on a queue

When something happens, write a notification job to a queue or a database table and return immediately. A separate worker picks up jobs and calls the provider. On shared hosting without a message broker, a jobs table processed by a scheduled task works well.

Retry with back-off

Temporary failures are normal. Retry after increasing delays — for example one minute, five minutes, thirty minutes — and stop after a set number of attempts. Mark permanent failures (an invalid number) so they are not retried.

Make sending idempotent

Give each notification a unique key, such as the order ID plus message type. If a job runs twice, the second run sees the key and does nothing. Customers should never receive the same receipt three times.

Watch the queue

• Alert when jobs pile up or the failure rate rises.
• Show staff the status of important messages.
• Keep failed jobs for investigation instead of deleting them.

Prioritise

One-time codes and security alerts should jump ahead of newsletters. Use separate queues or priorities.

Learn more about our messaging integration work.