System Design (High-Level Design) Module 26 – Case studies: booking, commerce and contention
Design an online auction
Design an online auction: one writer per auction for correct bid order, proxy bids, a soft close against sniping, live prices and finalising once.
What you will learn
- Estimate bids, fan-out to watchers and storage for an auction platform
- Order concurrent bids correctly under heavy contention with one writer per auction
- Explain proxy bidding, increments and ties with a worked example
- Prevent last-second sniping with a soft close and a hard stop
- Design finalisation that closes each auction exactly once, with a fallback to the runner-up
Before you start
What you’ll learn · Before you start
What you will learn
- Estimate bids, fan-out to watchers and storage for an auction platform
- Order concurrent bids correctly under heavy contention with one writer per auction
- Explain proxy bidding, increments and ties with a worked example
- Prevent last-second sniping with a soft close and a hard stop
- Design finalisation that closes each auction exactly once, with a fallback to the runner-up
Before you start
On this page
An online auction sells one item to whoever bids the most before a deadline, and its design must decide every bid in one order even when 3,000 of them arrive in the last minute. All bids for an auction go to one writer that owns it, which accepts a bid only if it beats the current price by at least one increment and stores it durably before answering. Bidders enter the most they will pay and the auction bids for them, which is proxy bidding; a bid in the final minutes moves the end, which is a soft close; and the writer’s own clock decides what was in time.
Watchers see the price over server-sent events or WebSocket connections fed by the writer. When the auction ends, a finaliser closes it once, charges the winner and offers the item to the runner-up if the winner’s payment fails. First you size the platform yourself and follow one bid through that design.
The last minute decides the auction, and the first design orders every bid
What makes an auction different
All the contention is on one value, the price of one item, and it peaks at the end, when every serious bidder acts. Order matters twice over: the earlier of two equal bids wins, and a bid that arrives after the end is refused. Far more people watch than bid, so telling everyone the price costs more than deciding the bids. And the end is a deadline with money attached: one winner, charged once.
Walk through the life of one auction, from the listing to the payment:
- Listed
The seller sets the rules
The seller lists an item with a start price, an optional reserve and an end time. From then on, every bid of this auction is decided in one order.
- The days before
A few bids, many watchers
Bids arrive now and then, and far more people watch the price than bid, so telling everyone the price soon costs more than deciding the bids.
- The last minute
Every serious bidder acts the peak
The contention peaks at the end, when a popular auction can take thousands of bids in its final minute, all for one value, the price of one item.
- The end time
Late bids move the end
A bid in the final minutes moves the end, so other bidders have time to answer, and a bid that arrives after the end is refused.
- After the end
Closed once, charged once
A finaliser closes the auction once and charges the winner; if the winner's payment fails, the item is offered to the runner-up.
The timeline has 5 events, from Listed to After the end.
Requirements
Sellers list an item with a start price, an optional reserve and an end time. Bidders place bids with a maximum, see the current price and whether they lead, and hear when they are outbid. When the auction ends, the winner pays, or the runner-up is offered the item. The qualities: every bid of an auction is decided in one order; an acknowledged leading bid is never lost; bidders get an answer within 200 ms even in the last seconds; watchers see a new price within a second; each auction is finalised exactly once.
Estimates
Assume 20 million bids a day with 12 % of them in the busiest hour, one popular auction that takes 3,000 bids in its final minute and has 100,000 watchers, and a 200-byte record for every bid, kept for a year. Work each figure out, then check yourself.
Checkpoint
Check the estimate
| Quantity | Working | Result |
|---|---|---|
| Bids, busiest hour | 20 million a day × 12 % ÷ 3,600 s | about 667 a second |
| One popular auction, final minute | 3,000 bids ÷ 60 s | 50 a second |
| Its watchers, if every bid is sent | 50 bids a second × 100,000 watchers | 5 million messages a second |
| Bid log | 20 million a day × 200 bytes × 365 | about 1.46 TB a year |
The bids are easy for one writer; the fan-out to watchers is the largest number by far.
The first design
The first design of an online auction
Text description of the diagram
The diagram shows the path of a bid from top to bottom, and the end of an auction.
- Bidders and watchers connect to the API and connection gateways, which keep server-sent events or WebSocket connections open.
- A bid goes to the bid router, which sends it to the writer that owns its auction.
- The auction writer, one per auction, applies proxy bids, increments and the end time. It appends each accepted bid to a durable bid log, in order, before it answers.
- The writer sends each new price to the price updates for the auction's channel, and a dashed arrow shows those updates going back through the gateways to watchers.
- An end-time scheduler starts the finaliser at the end time. The finaliser closes the auction at its writer, once per auction, and charges the winner through payment, or the runner-up if the winner's payment fails.
A bid enters through the gateways and the router sends it to the writer that owns its auction. The writer applies the bidding rules, appends the result to a durable bid log and only then answers the bidder. Each new price goes to the auction’s update channel and out to every connected watcher. An end-time scheduler starts the finaliser, which closes the auction at its writer and charges the winner.
Step through one bid, from the bidder’s app to the watchers, and then the end:
The drawing shows the whole scene; its 7 steps are listed below.
Every step as text
- A bid with a maximum. The bidder enters the most they will pay, and the app sends the bid through a gateway that also keeps the app's live connection open.
- To the auction's writer. The router sends every bid of auction 77 to the one writer that owns it, so all of that auction's bids are decided in one place, in one order.
- One place decides. The writer applies the bidding rules, the increments and the end time, and works out who leads.
- Logged before the answer. The writer appends the result to the durable bid log, in order, and only then answers the bidder, so an acknowledged leading bid is never lost.
- The new price goes out. The writer sends the new price to the auction's update channel, and the gateways pass it to every connected watcher within a second.
- Watchers see it. The update reaches the watchers through the gateways that hold their connections, over server-sent events or a WebSocket.
- The end, once. At the end time the finaliser closes the auction at its writer, once, and charges the winner, or offers the item to the runner-up if the payment fails.
Checkpoint
Check the first design
The deep-dive questions
- How are concurrent bids on one auction applied in a correct order, and what does that cost?
- How do proxy bids set the price, and who wins a tie?
- How does the auction stop last-second sniping without running for ever?
- Whose clock decides whether a bid was in time?
- How do 100,000 watchers see the price within a second?
- How is each auction finalised exactly once, and what happens when the winner does not pay?
- What breaks at 10× and 100×, and which designs are rejected?
One writer per auction applies every bid in order Pro: opens with a Pro, Premium or Ultimate pass
In this part:
- Reading, then writing loses bids
- The writer must not wait for a disk on every bid
- Proxy bids set the price from the maxima, worked
- A soft close stops sniping, measured
- One clock decides every deadline
- Price updates fan out at two a second, in two levels
- A claimed, idempotent finaliser closes each auction exactly once
- Shill bids, retractions and reserves have rules of their own
- At 10× the writers’ machines give way first, and at 100× the fan-out
- Failure drills: five faults, each with a safe way out
- Options considered and rejected
- What each level covers, and a 45-minute self-mock
- What each level is expected to cover
- A 45-minute self-mock
- Practise: a soft close in code, then the whole design
- Accept bids with increments, a soft close and a hard stop
- Interview questions
- Bidders complain that in the last seconds of busy auctions their higher bid was accepted and then disappeared. Each bid request reads the auction's row, compares in the application and writes the row back. Explain what happens, and redesign bid handling so that no acknowledged bid is lost.
- Most of your auctions are won by bids placed in the final two seconds, and sellers say their prices are too low. Would a soft close fix it, how long should the extension be, and what else would you change?
- After a scheduler failover, some auction winners were charged twice, and a few auctions never closed. Design finalisation so that each auction ends exactly once, including when the winner's payment is declined.
- Key takeaways
5 diagrams · 4 runnable examples (JavaScript, Python) · 1 exercise with sample tests · 3 interview answers · about 55 minutes
Opening this part with your pass…
This part opens with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so this part can’t be opened at the moment. The free part above stands on its own. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
Read a complete sample first: Design movie seat booking like BookMyShow
References
- PostgreSQL documentation: explicit locking, row-level locks (The PostgreSQL Global Development Group)
- HTML Living Standard: server-sent events (WHATWG)
- RFC 6455: The WebSocket Protocol (IETF)
- Orleans: request scheduling (Microsoft)
- Idempotent requests (API reference) (Stripe)
Related tools
Report a problem with this lesson
Kept only in this browser. Your Learn progress