SNS
Pub/sub fan-out to queues, functions, HTTP and mobile push.
Problem it solves: Producers and consumers run at different speeds and fail independently.
Where it sits: Between a producer service (async edge) and workers.
When to use
- Smoothing bursts; retries with back-off; work that can be deferred.
When not to use
- When the caller needs the result in the same request.
- As a fix for permanently insufficient consumer capacity.
Failure modes
- Backlog grows without bound when arrival rate > drain rate.
- Poison messages block consumers without a DLQ.
Metrics to watch
- Queue depth (messages)
- Oldest message age / consumer lag (s)
- Enqueue vs dequeue rate (msg/s)
Alternatives
- Event stream (Kafka-style log)
- Direct synchronous call
Configuration in Labs (illustrative defaults)
- Queue capacity (messages) = 1000000 — Messages the queue can hold. Beyond this, new messages are rejected (dropped).
- Base service time (ms) = 5 — Processing time per request at zero load. Queueing adds to this as utilisation rises.
Vendor examples (pattern only): AWS managed service. Simulated as a generic “Message queue”.