Design an online auction system

Quick Overview

This question evaluates system design skills—scalable distributed architecture, real-time messaging and push, concurrency and consistency under contention, API and data-model design, throughput estimation, and partitioning strategies—and is categorized under System Design.

Design an online auction system

Company: Meta

Role: Software Engineer

Category: System Design

Difficulty: easy

Interview Round: Onsite

Design a scalable online auction service. Users can: - Create an auction (item info, start/end time, reserve price optional). - Place bids while the auction is live. - See the current winning bid and bid history. - Receive near-real-time notifications when the winning bid changes and when the auction ends. Design goals and constraints: - Many auctions run concurrently; bids can spike near the end. - Correctness: determine the winner unambiguously; prevent accepting bids after the end time. - Low latency for bid placement and for notifying watchers. - The system should scale horizontally. What APIs, data model, storage, messaging/pub-sub, and real-time push mechanism would you use? Include a rough QPS/throughput estimation approach and how you would partition/shard data (e.g., by auctionId).

Quick Answer: This question evaluates system design skills—scalable distributed architecture, real-time messaging and push, concurrency and consistency under contention, API and data-model design, throughput estimation, and partitioning strategies—and is categorized under System Design.

|Home/System Design/Meta
Meta logo
Meta
Mar 11, 2026, 12:00 AM
easySoftware EngineerOnsiteSystem Design
13
0

Design a scalable online auction service.

Users can:

  • Create an auction (item info, start/end time, reserve price optional).
  • Place bids while the auction is live.
  • See the current winning bid and bid history.
  • Receive near-real-time notifications when the winning bid changes and when the auction ends.

Design goals and constraints:

  • Many auctions run concurrently; bids can spike near the end.
  • Correctness: determine the winner unambiguously; prevent accepting bids after the end time.
  • Low latency for bid placement and for notifying watchers.
  • The system should scale horizontally.

What APIs, data model, storage, messaging/pub-sub, and real-time push mechanism would you use? Include a rough QPS/throughput estimation approach and how you would partition/shard data (e.g., by auctionId).

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...