Queues that absorb a traffic spike

Place an order

Beginner

1. You click “Place order”.
2. The shop drops your order into the waiting line.
3. The line confirms your order is safely stored.
4. You see “Order received!” straight away, even though nothing has been packed yet.
5. A worker picks your order from the front of the line.
6. The worker records your order.
7. The database confirms it’s saved.
8. The worker tells the line this order is done, so it’s removed.

Practitioner

1. The client sends the order to the API.
2. The API checks the order and sends it to the queue.
3. The queue confirms the message is durably stored.
4. The API answers immediately. The real work happens later.
5. A worker pulls the next message.
6. The worker processes the order and writes it to the database.
7. The write succeeds.
8. The worker deletes the message from the queue.

Architect

1. POST /orders reaches the producer.
2. SendMessage after validation; payload kept small, large data stored by reference.
3. Ack once the message is replicated across zones.
4. 202 Accepted: user latency is decoupled from processing time.
5. ReceiveMessage; the message is hidden for the visibility timeout.
6. Idempotent write keyed by order ID, since delivery is at-least-once.
7. Commit acknowledged.
8. DeleteMessage; had the worker crashed, the message would reappear after the timeout.

Traffic spike

Beginner

1. A flash sale starts and thousands of shoppers click at once.
2. Every order still drops straight into the line. The line just gets longer.
3. Everyone still sees “Order received!” quickly.
4. Workers keep taking orders one by one. More helpers can join if the line gets long.
5. The database gets a steady trickle instead of a flood, so it never falls over.

Practitioner

1. Order requests jump to many times the usual rate.
2. The API keeps enqueuing; the queue grows.
3. Users get fast confirmations despite the spike.
4. Workers process at their own pace and can scale out on queue length.
5. Database writes stay at a safe, steady rate.

Architect

1. Producer rate far exceeds steady-state consumer throughput.
2. Queue depth climbs; producers are unaffected by consumer speed.
3. Latency stays flat for users; the backlog is absorbed by the queue.
4. Autoscale consumers on ApproximateNumberOfMessages or age of oldest message.
5. Bounded consumer concurrency caps DB write pressure; the backlog drains after the peak.

Bad message

Beginner

1. A worker picks up an order that has something wrong with it.
2. The worker can’t handle it, so the order goes back in the line.
3. Another try, in case the problem was temporary.
4. It fails again. Some orders just can’t be processed.
5. After a few tries, the order is moved to a separate pile so it stops blocking the line. Someone can look at it later.

Practitioner

1. A worker receives a malformed message.
2. Processing fails; the message becomes visible again.
3. The message is retried.
4. It fails again.
5. The queue moves it to the dead-letter queue.

Architect

1. Receive #1 of a poison message.
2. No delete; the visibility timeout expires and the message is redelivered.
3. Receive #2. Transient failures usually succeed here.
4. Still failing; receive count reaches maxReceiveCount.
5. Redrive policy moves it to the DLQ; an alarm on DLQ depth pages a human.