Sending queue with retries — a reminder is not lost in an outage
Emails are queued and retried on failure, with a growing gap between attempts.
The problem
An email sent at the exact moment of a network incident disappears without trace. It is not frequent, but over hundreds of messages a month it happens in the end — and it happens to a reminder, the day before an appointment, with nobody the wiser.
Sending directly at the moment of the action has a second flaw: it slows down what the user is doing. The booking waits for the mail server to answer, and if that takes ten seconds, the client watches a spinning page wondering whether their click worked.
Decoupling the action from the sending fixes both problems at once.
How it works in Kagenda
Messages are not sent on the back of the action: they are dropped into a queue which a process works through continuously.
- The message is queuedThe booking finishes immediately for the client, without waiting for the mail server.
- The queue is worked through continuouslyA process regularly picks up the waiting messages and sends them.
- Failures are retriedA send that fails is picked up later, with a gap that lengthens on each attempt — enough to ride out a passing outage without saturating the service.
- Persistent failures are flaggedThe calendar shows the messages that did not go out, so that you can resend or correct the address.
Who it helps
Frequently asked questions
How long can a message wait?
In normal operation, a few seconds. Retries only come into play on failure, and the calendar flags whatever did not go out in the end.
Is a late reminder still sent?
Yes, the queue picks the waiting messages back up. A reminder that goes out a few minutes late is still useful; that is better than a lost one.
How do I see the failures?
They are flagged in the calendar, on the bookings concerned, which lets you act before the appointment.