Online auction (eBay)

01 · CONTEXT

Competing for an item until the auction ends

An online auction service lets users list items for sale and lets other users compete to buy them. The competition happens through bids: each new bid must beat the current highest bid until the auction ends, and whoever has the highest bid gets the item.

This article uses only the public part of the reference page; what it keeps behind the paywall is not claimed here.

02 · REQUIREMENTS

Three actions and a scope boundary

There are three core requirements. Post an item with a starting price and an end date; place a bid on an item, with the bid accepted only if it is higher than the current highest bid; and view an auction, including the current highest bid.

Explicitly out of scope are item search, category filtering, price sorting, and looking up an item's auction history.

03 · BASIC FLOW

The path of posting, bidding, and viewing

The sketch below is our own reading of the three requirements, not a design reproduced from the source: an auction service behind a gateway, with a database that stores items and bids. It does not yet handle concurrency or real time; it serves as a basis for the questions in the next section.

1. The seller submits the item with a starting price and an end date; the request enters through the gateway.

2. The auction service writes the item to the database, which now represents an open auction.

3. A buyer sends a bid for the item.

4. The service accepts the bid only if it is higher than the item's current highest bid.

5. Whoever views the auction receives the item with the current highest bid.

04 · DEEP DIVES

Where the problem really gets tight

The page lists four deep-dive questions: how to ensure strong consistency for bids, how to make the system fault tolerant and durable, how to display the current highest bid in real time, and how to scale to ten million simultaneous auctions.

05 · PATTERNS

Contention and live updates

The page classifies the problem with two patterns: contention over a single resource (Dealing with Contention) and real-time updates (Real-time Updates).

To study the first, it is worth reviewing consistency and its guarantees; for the second, the communication protocols, and for frequent reads of the current value, the cache fundamentals.

The second sketch shows only one possible way to get an accepted bid to those following the auction, using an event queue and a broadcast service. It is an illustration of the course's reasoning, not the source's solution.

1. The bidder sends the bid to the bidding service.

2. The service validates the bid against the current highest bid and writes the result to the database.

3. For each accepted bid, the service publishes an event to the queue.

4. The broadcast service consumes the event without holding up the bid write.

5. Those following the auction receive the new value without reloading the page.