Message platform for fan-out
Send each notification through a Queue and Workers to a managed provider, so a slow or failing send never holds a request.
Send a notification from a Worker to a managed provider, not from the App Server that took the request.
Move up when#
Users expect push or email after an event, and each send holds an App Server slot.
A provider's slow answer or outage shows up as slow pages.
One event must reach many receivers, and the sends are growing.
The Design#
Drag to pan. Hold Ctrl or Cmd and scroll to zoom.
| Where | Setting | Value | Why |
|---|---|---|---|
| App Server | Instance size | small | It only hands the notification to the Queue. |
| Database | Instance size | small | Serves the reads and writes the rest of the traffic makes. |
| Queue | Dead-letter queue | On | A notification that fails every time is parked, not retried forever. |
| Worker | Copies | 2 | The Workers do the sending, so more copies mean the Queue drains faster. |
| Link Worker → Push Provider | Timeout | 5 s | A provider that stalls should free the Worker in seconds, not hold it for the default wait. |
| Link Worker → Push Provider | Retries | backoff | A failed send is tried again after a growing delay, so a provider blip does not drop notifications. |
Research this Design needs: Message queues, Background jobs, Notifications, Background jobs, Message queues, Notifications, Timeouts and retries, Backoff with jitter.
The App Server enqueues the notification and returns. The Workers take it and call the Push Provider. That Link has a Timeout and a Retries policy, because the provider is a third party and the Worker has to protect itself from it.
Why it works#
The user never waits for the send. A stalled provider holds a Worker for seconds, not for the default wait, and the Queue absorbs the backlog while the provider recovers. Retries with backoff cover a short blip without hammering the provider.
A managed provider costs nothing to place and charges per message, so you pay for volume and run no sending fleet.
What it costs#
Delivery is at least once, so a notification can arrive twice unless the send is idempotent. The game has no topic with many subscribers, so this shows the simplest fan-out: one task, one provider. A real platform adds topics, and you can read about them on Publish-subscribe. Backoff delays a failed send, so urgent messages lose time.
In Quorum#
The Push Provider needs Notifications, and it sits behind the Queue and Worker of the last rung. Both Link settings need Timeouts and retries, and backoff needs Backoff with jitter. The Timeouts and Retry with backoff pages explain the two Link settings. The next rung covers spiky work with no box: Functions for spiky jobs.