
🛒 Retail & E-commerce · Deployment · Pro
How an online store survives a flash sale: CDN, a virtual waiting room, autoscaling and a queue in front of the order system.
Deployment diagrams are part of Pro. Anyone can view this one; generating and editing it needs Pro.
Drawing diagram…
Deployment for a flash sale: shoppers hit a CDN serving static pages, a virtual waiting room admits users at a controlled rate, then a load balancer in front of an autoscaling group of web/API servers. Sale stock is held in Redis and decremented atomically, confirmed orders go into a queue (SQS/Kafka) and order workers write to the database at a steady rate. Read replicas serve product pages.
flowchart TB
U[Shoppers] --> CDN[CDN - static pages]
CDN --> WR[Virtual Waiting Room]
WR -->|Admit at controlled rate| LB[Load Balancer]
subgraph ASG[Autoscaling group]
A1[API Server]
A2[API Server]
A3[API Server N]
end
LB --> A1
LB --> A2
LB --> A3
A1 --> R[(Redis - sale stock, atomic decrement)]
A2 --> R
A3 --> R
A1 --> Q[Order Queue]
A2 --> Q
Q --> W[Order Workers]
W --> DB[(Primary DB)]
DB --> RR[(Read Replicas)]
RR --> A3An online store split into microservices: catalog, cart, orders, payments and search, with Kafka events connecting them to shipping and notifications.
What happens when a shopper clicks Pay: stock is reserved, the payment is authorised, the order is created and stock is released again if payment fails.
Every status an online order moves through, from placed to delivered, including cancellations, returns and refunds.
A flexible product catalog: categories, products with variants (size, colour), prices, stock per warehouse and images.
How stock stays in sync across stores, warehouses and marketplaces so the same item isn't sold twice.
How an online store handles a return: eligibility, pickup, quality check at the warehouse and the refund or replacement.