The sale opened. The orders vanished.

Understand it one step at a time

The short runs these in order in about 33 seconds. Here they are written out — pick any step to jump the short straight to it.

1. 1

   11:00 AM — the flash sale opens

   12,000 shoppers hit Buy inside the same minute. One order API is listening.

   msdevbuild.shop · sale is live

2. 2

   Every order hits one server

   No buffer in between. Each request has to be accepted, validated and written right now.

   order-api · 940 requests/sec inbound

3. 3

   The server stops keeping up

   CPU pinned at 100%. Timestamps freeze mid-tick — the backlog is now inside the server.

   order-api · CPU 100% · degraded

4. 4

   Real orders, gone

   Connections time out. 1,729 shoppers see an error page — that is lost revenue, not lost packets.

   HTTP 503 · 1,729 orders dropped

5. 5

   Fix: Azure Service Bus

   Put a broker in front. The API has one job now — accept the order and enqueue it.

   orders-queue · created

6. 6

   Every order lands in the queue

   Enqueue takes milliseconds, so nothing is rejected. The timestamps keep ticking.

   orders-queue · 1,204 messages waiting

7. 7

   The worker pulls at its own pace

   Service Bus holds the burst. The consumer takes one message, completes it, then asks for the next.

   worker-1 · receive → complete → repeat

8. 8

   Failed? It comes back

   An uncompleted message is redelivered automatically. Need it faster? Add workers to the same queue.

   redelivery 1/10 · workers 1 → 3

9. 9

   Same minute, two outcomes

   Identical traffic. One design drops paying customers, the other absorbs the spike and keeps counting.

   9,842 processed · 0 lost

10. 10

    Every order. Every time.

    The queue is the shock absorber between a spike you cannot control and a server you can.

    Azure Service Bus · orders-queue