# The sale opened. The orders vanished.

> What a queue actually does to a traffic spike your server cannot absorb.

- **Format:** short video, 10 steps, ~33 seconds
- **Topic:** Azure Service Bus — how a queue in front of the order API stops a flash sale from dropping real customer orders.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure
- **Tags:** azure, azureservicebus, servicebus, messagequeue, systemdesign, microsoftazure, azurecloud, cloudarchitecture, dotnet, backenddeveloper, devops, az305, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/azure-service-bus-flash-sale/

---
## What you'll learn

- What a flash sale does to an order API with nothing in front of it
- How a queue decouples arrival rate from processing rate
- Why an uncompleted message comes back without a retry loop

## Understand it one step at a time

### 1. 11:00 AM — the flash sale opens

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

### 2. Every order hits one server

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

### 3. The server stops keeping up

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

### 4. Real orders, gone

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

### 5. Fix: Azure Service Bus

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

### 6. Every order lands in the queue

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

### 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.

### 8. Failed? It comes back

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

### 9. Same minute, two outcomes

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

### 10. Every order. Every time.

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

---

## The takeaway

**A queue is a design decision, not a library**

Decouple the arrival rate from the processing rate, and a spike stops being an outage.