Your country

Tools that support it use your country for local currency, number formats, units and paper size. Your choice is saved only in this browser.

Type a name or a two-letter code. Use the up and down arrow keys to move through the countries, Enter to choose one and Escape to close.

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.

  • Intermediate
  • 30 minutes
  • Examples run with Python 3.14.8, Pyodide 314.0.7, Node.js 24.21.0 and quickjs 0.32.0
  • By MySmartCoPilot
Free intro, Pro: 6 of 30 minutes free
Free: The last minute decides the auction, and the first design orders every bid. With a pass: the other 14 sections and 3 interview answers, about 24 minutes.

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:

Timeline · 5 events in order The life of one auction, as the design sees it Walk through one auction from the listing to the payment, and see when the load and the risk peak.
  1. 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.

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

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

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

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

  1. Question 1 of 3 Where does the contention of an online auction peak?

    Choose one answer.

    Show the answer: Question 1 of 3

    Answer: At the end, on one value, the price of one item

    All the contention is on one value, the price of one item, and it peaks at the end, when every serious bidder acts. The earlier of two equal bids wins, and a bid that arrives after the end is refused.

  2. Question 2 of 3 The platform receives 20 million bids a day, and the busiest hour carries 12 % of them. How many bids a second is that?

    Type a number.

    A hint

    Work out the bids of the busiest hour first, then divide by the seconds in an hour.

    Show the answer: Question 2 of 3

    Answer: 667 bids a second (anything from 600 to 734 counts)

    20,000,000 × 0.12 = 2,400,000 bids in the busiest hour, and 2,400,000 ÷ 3,600 ≈ 667 a second across all auctions. Spread over many auctions that is modest; the difficulty is that one auction can take many of them in its last minute.

  3. Question 3 of 3 A popular auction takes 3,000 bids in its final minute and has 100,000 watchers. If every accepted bid were sent to every watcher, how many messages a second would that be?

    Type a number.

    A hint

    Find the bids a second first, then multiply by the watchers.

    Show the answer: Question 3 of 3

    Answer: 5000000 messages a second (anything from 4500000 to 5500000 counts)

    3,000 ÷ 60 = 50 bids a second, and 50 × 100,000 = 5,000,000 messages a second for one auction. The bids are cheap; telling everyone about them is the expensive part of the design.

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

Auction design: bids go to one writer per auction, which logs them and sends prices to watchers; a finaliser closes each auction.Bidders and watchersAPI and connection gatewaysserver-sent events or WebSocketBid routerauction id to its writerAuction writer, one per auctionproxy bids, increments, end timeBid logdurable, in orderPrice updatesone channel per auctionEnd-time schedulerFinaliseronce per auctionPaymentwinner, then runner-upbidappend, then answernew priceupdatesat the end timeclosecharge

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.

  1. Bidders and watchers connect to the API and connection gateways, which keep server-sent events or WebSocket connections open.
  2. A bid goes to the bid router, which sends it to the writer that owns its auction.
  3. 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.
  4. 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.
  5. 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:

Interactive · step by step One bid through the first design Step through one bid from the bidder's app to the watchers, then the end of the auction.
One bid through the first design, step 7 of 7. Showing Bidder, Gateways, Bid router, Auction writer, Bid log, Price updates, Finaliser, Payment. In focus: Finaliser.bidappend, then answernew priceclosechargeBidderGatewaysAPI, SSE or WebSocketBid routerauction id to its writerAuction writerone per auctionBid logdurable, in orderPrice updatesone channel per auctionFinaliseronce per auctionPaymentwinner, then runner-upcharge the winner

The drawing shows the whole scene; its 7 steps are listed below.

Every step as text
  1. 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.
  2. 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.
  3. One place decides. The writer applies the bidding rules, the increments and the end time, and works out who leads.
  4. 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.
  5. 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.
  6. Watchers see it. The update reaches the watchers through the gateways that hold their connections, over server-sent events or a WebSocket.
  7. 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

  1. Question 1 of 2 Which of these must answer before a bidder is told whether their bid leads? Choose every one.

    Choose every answer that is right.

    Show the answer: Question 1 of 2

    Answer:

    • The bid router that finds the auction's writer
    • The auction's writer
    • The durable bid log

    A bid is decided by the auction's writer and must be in the durable log before the bidder hears that it leads, so the router, the writer and the log are on its path. Watchers hear afterwards, and payment happens at the end.

  2. Question 2 of 2 A teammate wants the writer to answer the bidder first and append to the bid log a moment later, to save time. Which requirement does that break?

    Choose one answer.

    Show the answer: Question 2 of 2

    Answer: An acknowledged leading bid is never lost

    The writer appends the result to a durable bid log and only then answers the bidder, so that an acknowledged leading bid is never lost. Answering first opens a window in which a crash loses a bid someone was told leads.

The deep-dive questions

  1. How are concurrent bids on one auction applied in a correct order, and what does that cost?
  2. How do proxy bids set the price, and who wins a tie?
  3. How does the auction stop last-second sniping without running for ever?
  4. Whose clock decides whether a bid was in time?
  5. How do 100,000 watchers see the price within a second?
  6. How is each auction finalised exactly once, and what happens when the winner does not pay?
  7. 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.

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

Related tools

Report a problem with this lesson

Quick answers and tool search

Type to search tools or to get a quick answer, for example 18% of 2500. Use the up and down arrow keys to move through the results, Enter to choose, and Escape to close.