How the interviewer opens it
“Design an online auction platform where sellers list items and buyers submit bids. Each auction closes at a set time and selects a winner.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Auction format
- Bid rules
- Deadline and winner
- Daily scale and request mix
- Peak traffic
- Latency
- Consistency and availability
- Durability and retention
- Client retries
- Scope limits
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Create an auction for one item with a start price and a fixed close time
- View an auction and its current price
- Submit a bid and receive a clear decision
- Close an auction and record its final winner
Usually out of scope
- Payments and shipment
- Proxy bids and reserve prices
- Bid withdrawal and deadline extensions
- Account creation
- Writes across multiple regions
What interviewers ask about
- Concurrent bids
- Every accepted bid changes the price for later bids. Many requests compete for the same auction state.
- The auction deadline
- A close task can arrive late while bids wait for access. The service must apply one deadline rule to both paths.
- An uncertain bid result
- A timeout does not reveal whether the service accepted a bid. A failover can also expose an outdated auction state.
- Traffic for one auction
- More database partitions do not remove contention within one auction. Public reads can also overwhelm the same item.
Common mistakes
- Trusting the price that the buyer saw instead of the authoritative auction state
- Checking the deadline only when the close task runs
- Recording a bid separately from the auction's price change
- Treating a timeout as proof that the bid failed
- Using database partitions as the answer to contention within one auction
- Acknowledging bids before durable commit
The bar by level
- Senior (L5/E5)
- Defines the decision order and deadline boundary. Handles retries, delayed close tasks, and crashes. Separates public reads from bids and calculates hot-auction capacity.
- Staff (L6+/E6+)
- Sets explicit guarantees for overload and failover. Preserves those guarantees through batches, clock uncertainty, and primary changes. Explains why partitions cannot remove one auction's serial limit.