Design an online auction system

Quick Overview

This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design an online auction system states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

System Design: Real-Time Online Auction Platform

You are asked to design an online auction system that supports real-time bidding at web scale. Assume a mix of desktop and mobile clients, global users, and many concurrent auctions.

Functional Requirements

Listing lifecycle: create, view, edit (before first valid bid), cancel (with restrictions), close.
Bidding: real-time bids, enforced minimum increments, reserve prices, buy-it-now, and anti-sniping protections.
Closeout: determine winner, collect payment, notify parties, and finalize auction state.
Real-time updates: push current price, bid events, reserve met status, time-left/extension, and closeout results to watchers.

Non-Functional Requirements

High availability and scalability across many concurrent auctions and watchers.
Strong consistency for winner determination and money-related state.
Low-latency bid processing and fanout (<200–300 ms p95 event-to-update as a target).
Observability, fraud detection, and reliable payments/settlement.

Deliverables

APIs (HTTP and real-time) for listings, bids, and buy-it-now.
Data model (schemas/entities, indexes) and event model.
Consistency model for winning bids and concurrency control strategy.
Real-time update design (WebSocket/streaming), ordering, and backpressure.
Anti-sniping policy and auction closeout flow.
Fraud detection hooks and controls.
Payments and settlement flows with idempotency.
Scalability, fault tolerance, and monitoring strategy.

Assume minimal context as needed (e.g., auctions are priced in a single currency; times are UTC).

Clarifying Questions to Ask Guidance

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?

Design an online auction system

Quick Overview