Design an online auction system

Last updated: Mar 29, 2026

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.

|Home/System Design/Meta

Design an online auction system

Meta

Aug 7, 2025, 12:00 AM

hardSoftware EngineerTechnical ScreenSystem Design

6

0

Design an online auction system

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

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

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?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Meta•More Software Engineer•Meta Software Engineer•Meta System Design•Software Engineer System Design

Your design canvas — auto-saved