Commerce & payments · Intermediate

Flash sale

Limited drop that sells from an atomic Redis counter and writes orders through a queue.

Every part, and why it is there

Shoppers & bots

At 10:00:00 a huge crowd (and a lot of bots) all press Buy for 5,000 pairs of shoes. Traffic goes from almost nothing to a wall in under a second.

CDN

The drop page is the same for everyone, so it is served entirely from the edge. Origin servers only ever see the Buy button, never the page views.

Pre-rendered drop page

The page is rendered ahead of time and uploaded as a static file. Nothing about it needs a database query on sale day.

WAF / bot filter

Blocks known bots and scripted bursts before they cost anything. In a flash sale most of the traffic can be automated, so this is a capacity feature, not just security.

Edge throttle

A leaky bucket in front of checkout: it lets through only as many buyers per second as the backend can handle and tells the rest to wait and retry.

Admission service

POST /drops/:id/purchase decides “you got one” or “sold out” in a few milliseconds by decrementing a counter. It does not write the order itself, which keeps it fast.

Stock counter (Redis)

Stock is a single number and DECR is atomic, so thousands of concurrent buyers can never oversell. A database row would become one hot lock every request fights over.

Order queue

Winners are put on a queue so the order database fills at a steady pace. The spike is absorbed here instead of in the database.

Order workers

Turn each winning reservation into an order and take payment. If payment fails they give the unit back to the counter.

Orders DB

Stores orders durably at the rate the workers write, not the rate shoppers click.

Payment provider

Payment is charged off the hot path. A slow provider makes confirmations later, but never oversells or overloads the site.

Order status API

The app polls here to show “processing → confirmed”. It reads from the orders DB, so the buyer sees the real outcome once the worker finishes.

Asked in interviews at

  • miq-digital
  • salesforce

Concepts used here

  • Caching: Keep recent answers in memory so the database only does each piece of work once. Then deal with the three ways that goes wrong: stale data, a full cache, and a stampede.
  • Load balancing: One address in front of many servers. Follow one shopper’s request on sale day through DNS, the balancer’s choice of server, a crash, and back.
  • Message queues: Let the fast part of your app reply now and the slow part catch up later. Nothing is lost in a rush, but any job may run twice, so make twice harmless.
  • HTTPS: Follow one password typed on café Wi-Fi, first over plain HTTP, where anyone nearby can read it, then over HTTPS: a secret agreed in public, a certificate that proves who the server is, and encryption for everything after.
  • Token bucket: A rate limit with two knobs: how fast permits come back, and how many can pile up. Set both and a real app’s burst gets through while a flood does not.

Learn more

All system design examples