Design: Online Auction (eBay-style bidding)¶

Difficulty: Senior | Time: 60–75 minutes

1. Problem Statement¶

Design a service like eBay: sellers create listings, buyers place competing bids in real time, and the highest bid at a fixed close time wins. Two properties make this harder than most CRUD systems:

1. Strict per-item bid ordering under concurrency. A bid is valid only if it exceeds the current highest bid at the moment it is evaluated. Two bidders submitting near-simultaneously on the same popular item must be resolved deterministically — no double-acceptance, no lost higher bid, no ambiguity about who was actually leading when.
2. A hard time boundary with a fairness problem baked in. The auction closes at an exact end_time. Bids arriving in the final second are exactly as valid as bids from an hour earlier, but network jitter means a bidder with worse latency can have their earlier, higher intent arrive after a later, lower bid from someone closer to your servers — a race your system, not the network, is responsible for resolving fairly. This is the classic "sniping" problem: bidders wait until the last moment to bid, and an outbid buyer needs a real chance to respond, or the auction becomes a latency contest instead of a price contest.

Do not start with "just use a database with a highest-bid column." That handles requirement 1 badly and requirement 2 not at all. Decide first what "fair" and "final" actually mean before drawing boxes.

2. Clarifying Questions¶

3. Functional Requirements¶

• Create a listing (title, description, images, starting price, reserve, start_time, end_time, bid increment rule)
• Place a bid on an active listing; reject if not strictly higher than current price (+ increment)
• View current price and full bid history for an item
• Support proxy/automatic bidding (bidder sets a max; system bids the minimum needed to stay ahead, up to that max)
• Close the auction at end_time and determine the winner, with anti-sniping extension if configured
• Notify outbid bidders in near-real-time so they can respond before close

4. Non-Functional Requirements¶

5. Capacity Estimation¶

Listings:
  200K new listings/day → ~2.3/s average, negligible write load

Live auctions:
  50K concurrently active auctions at peak

Bid traffic (steady state):
  Most auctions get a handful of bids over days — near-zero load
  Average across the platform: ~50 bids/second aggregate

Bid traffic (hot-item-closing-second spike):
  A popular item (rare sneaker drop, estate item) draws thousands of watchers
  In the last 10 seconds: up to 5,000 bid attempts on ONE item_id
  → 500 bids/sec on a single row/partition, for ~10 seconds
  This is the number that breaks a naive design — not the platform aggregate.

Reads:
  Browsing + live price polling/websocket: ~50K concurrent viewers on hot items
  Price update fan-out: 50K clients × 1 push per accepted bid ≈ bursty, but
  independent of write-path correctness (can be eventually consistent)

Bid log storage:
  Avg 20 bids/auction × 200K auctions/day × 200 bytes/bid ≈ 800 MB/day
  Trivial to store forever — this is the actual system of record, keep it all.

6. API Design¶

POST /api/v1/listings
Request:  { "title": "...", "starting_price": 10.00, "reserve_price": 50.00,
            "increment_rule": "min_increment", "start_time": "...", "end_time": "...",
            "anti_snipe_window_s": 30, "anti_snipe_extension_s": 60, "max_extensions": 10 }
Response: { "item_id": "abc123", "status": "scheduled" }

POST /api/v1/items/{item_id}/bids
Request:  { "amount": 105.00, "bidder_id": "u_42" }
Response 201: { "bid_id": "b_9981", "accepted": true, "current_price": 105.00, "sequence": 4821 }
Response 409: { "accepted": false, "reason": "bid_too_low", "current_price": 106.50 }
  -- 409, not 200-with-flag: a rejected bid is a distinct outcome the client must branch on

POST /api/v1/items/{item_id}/proxy-bids
Request:  { "max_amount": 150.00, "bidder_id": "u_42" }
Response: { "current_price": 105.00, "you_are_leading": true }
  -- system will auto-bid on the user's behalf up to max_amount as others bid

GET  /api/v1/items/{item_id}/price
Response: { "current_price": 105.00, "leading_bidder": "u_42" (masked), "end_time": "...", "extended": false }

GET  /api/v1/items/{item_id}/bids?limit=50
Response: [ { "bid_id": "b_9981", "amount": 105.00, "sequence": 4821, "ts": "...", "bidder": "u_4**" }, ... ]

WS   /ws/items/{item_id}   -- push current_price + outbid events to watchers

POST /internal/items/{item_id}/close   -- invoked by the close-scheduler, not clients

7. Data Model — the bid log is the source of truth, not a cache of it¶

A naive design stores only current_highest_bid on the listing row and overwrites it per bid. That throws away exactly the information you need most: who bid what, when, in what order, and whether a disputed "I was outbid unfairly" claim is true. Keep every bid, forever, as an append-only log.

CREATE TABLE listings (
    item_id         VARCHAR(20) PRIMARY KEY,
    seller_id       VARCHAR(20) NOT NULL,
    title           VARCHAR(200) NOT NULL,
    starting_price  NUMERIC(12,2) NOT NULL,
    reserve_price   NUMERIC(12,2),
    current_price   NUMERIC(12,2) NOT NULL,   -- DERIVED cache of the log's max; never the source of truth
    leading_bid_id  BIGINT,
    start_time      TIMESTAMPTZ NOT NULL,
    end_time        TIMESTAMPTZ NOT NULL,
    anti_snipe_window_s INT DEFAULT 30,
    anti_snipe_extension_s INT DEFAULT 60,
    extensions_used INT DEFAULT 0,
    max_extensions  INT DEFAULT 10,
    status          VARCHAR(16) NOT NULL,     -- scheduled | active | closing | closed | cancelled
    INDEX idx_end_time_status (end_time, status)
);

-- Append-only. Never UPDATEd, never DELETEd. This is the legal/audit record.
CREATE TABLE bids (
    bid_id       BIGSERIAL PRIMARY KEY,
    item_id      VARCHAR(20) NOT NULL,
    bidder_id    VARCHAR(20) NOT NULL,
    amount       NUMERIC(12,2) NOT NULL,
    sequence     BIGINT NOT NULL,          -- server-assigned, monotonic PER ITEM (not global)
    is_proxy_bid BOOLEAN DEFAULT FALSE,
    server_ts    TIMESTAMPTZ NOT NULL,     -- authoritative time; never trust client clocks
    accepted     BOOLEAN NOT NULL,         -- rejected bids are logged too, for dispute resolution
    reject_reason VARCHAR(32),
    UNIQUE (item_id, sequence),
    INDEX idx_item_seq (item_id, sequence)
);

CREATE TABLE proxy_bid_limits (
    item_id     VARCHAR(20) NOT NULL,
    bidder_id   VARCHAR(20) NOT NULL,
    max_amount  NUMERIC(12,2) NOT NULL,
    created_at  TIMESTAMPTZ NOT NULL,
    PRIMARY KEY (item_id, bidder_id)
);

8. Version 1 — simplest thing that works¶

Single Postgres row per item holding current_highest_bid. Accept a bid with a conditional update; a cron sweeps for closed auctions.

graph LR
    Client -->|POST bid| API[API process]
    API -->|UPDATE ... WHERE new_bid > current_price| PG[(Postgres\nlistings table)]
    Cron[Cron, every 5s] -->|SELECT WHERE end_time < now AND status=active| PG
    Cron -->|mark closed, pick winner| PG

def place_bid(item_id: str, bidder_id: str, amount: float) -> dict:
    row = db.execute("""
        UPDATE listings
        SET current_price = %s, leading_bidder = %s
        WHERE item_id = %s AND %s > current_price AND status = 'active'
        RETURNING current_price
    """, amount, bidder_id, item_id, amount)
    if row:
        return {"accepted": True, "current_price": row.current_price}
    return {"accepted": False, "reason": "bid_too_low_or_closed"}

# separate cron process, every 5 seconds
def sweep_closed_auctions():
    items = db.query("SELECT item_id FROM listings WHERE end_time < now() AND status = 'active'")
    for item in items:
        db.execute("UPDATE listings SET status = 'closed' WHERE item_id = %s", item.item_id)
        notify_winner(item.item_id)

The conditional UPDATE ... WHERE amount > current_price is atomic — Postgres row locking genuinely prevents two bids from both "winning" the same comparison. Ship this for low-traffic listings and find the real bottleneck before adding anything.

9. Identify the bottleneck¶

10. Version 2 — append-only bid log as the source of truth¶

Every bid is written to the log with a server-assigned, per-item monotonic sequence number and an authoritative server timestamp. "Current price" is derived by querying the max of the log, not stored-and-raced independently. Bid acceptance becomes a conditional insert against the log's current max — same atomicity guarantee as V1's row update, but now every attempt (accepted or not) is durable and orderable. Auction close moves from polling to a precise per-item timer, with anti-snipe extension handled as a rule evaluated at insert time.

graph TD
    Client -->|POST bid| API[Bid API]
    API -->|1: INSERT ... WHERE amount > (SELECT MAX(amount) FROM bids WHERE item_id=X)| PG[(Postgres\nbids log, per-item serialized)]
    API -->|2: on accept, check anti-snipe window| Sched[Close Scheduler]
    Sched -->|reschedule timer if within window| Sched
    Sched -->|fires exactly at end_time| Close[Close handler]
    Close -->|SELECT MAX by sequence, mark closed, atomically| PG

def place_bid(item_id: str, bidder_id: str, amount: float) -> dict:
    with db.transaction():                      # single serialization point per item
        listing = db.execute(
            "SELECT end_time, status FROM listings WHERE item_id=%s FOR UPDATE", item_id
        )
        if listing.status != 'active' or now() >= listing.end_time:
            return log_and_reject(item_id, bidder_id, amount, "closed")

        current_max = db.execute(
            "SELECT COALESCE(MAX(amount),0) AS m FROM bids WHERE item_id=%s AND accepted=true", item_id
        ).m
        if amount <= current_max:
            return log_and_reject(item_id, bidder_id, amount, "too_low")

        seq = next_sequence(item_id)             # monotonic counter, per item
        db.execute("""
            INSERT INTO bids (item_id, bidder_id, amount, sequence, server_ts, accepted)
            VALUES (%s,%s,%s,%s, now(), true)
        """, item_id, bidder_id, amount, seq)
        db.execute("UPDATE listings SET current_price=%s, leading_bid_id=%s WHERE item_id=%s",
                    amount, seq, item_id)

        # anti-sniping: extend if this bid landed inside the closing window
        remaining = (listing.end_time - now()).total_seconds()
        if remaining < listing.anti_snipe_window_s and listing.extensions_used < listing.max_extensions:
            new_end = now() + timedelta(seconds=listing.anti_snipe_extension_s)
            db.execute("UPDATE listings SET end_time=%s, extensions_used=extensions_used+1 WHERE item_id=%s",
                        new_end, item_id)
            close_scheduler.reschedule(item_id, new_end)

        return {"accepted": True, "current_price": amount, "sequence": seq}

The SELECT ... FOR UPDATE on the listing row is what gives you strict ordering: it's a single serialization point per item, so two bidders racing on the same item are forced through one at a time, in true database-commit order — the fairness question (who bid "first") is now answered by an authoritative server timestamp and sequence number instead of by whichever request happened to reach the socket first. That's still not perfect physical-world fairness (server receive time is still a proxy for "when the bidder clicked"), but it is now provable, logged, and consistent, which is the bar auctions actually need — you can show a disputing bidder the exact sequence.

Close precision: replace the cron with a scheduled timer per auction (a durable job scheduler — e.g. a per-item delayed job in a system like a Redis-backed timer wheel, SQS delay queues, or a dedicated scheduler service) that fires once at end_time, invoking /internal/items/{item_id}/close directly rather than being discovered by a periodic scan. Anti-snipe extensions reschedule that same timer forward rather than waiting for the next poll.

11. Identify the next bottleneck¶

The cascade below is bidder C placing a $100 manual bid on an item where proxy A (max $150) and proxy B (max $180) are both already standing — the whole resolution happens inside one transaction, under the same FOR UPDATE row lock used for manual bids, so no other bid can interleave mid-cascade:

sequenceDiagram
    participant C as Bidder C (manual bid)
    participant Engine as Bid/Proxy Engine
    participant Listing as listings row (FOR UPDATE)
    participant PA as Proxy A (max $150)
    participant PB as Proxy B (max $180)

    C->>Engine: POST /bids { amount: 100 }
    Engine->>Listing: SELECT ... FOR UPDATE
    Engine->>Engine: append bid log entry (C, $100)

    Engine->>PA: current_max=$100, does A respond?
    PA-->>Engine: yes, next_bid=$105 (<= $150 max)
    Engine->>Engine: append bid log entry (proxy A, $105)

    Engine->>PB: current_max=$105, does B respond?
    PB-->>Engine: yes, next_bid=$110 (<= $180 max)
    Engine->>Engine: append bid log entry (proxy B, $110)

    Engine->>PA: current_max=$110, does A respond?
    PA-->>Engine: no — next_bid would be $115, still <= $150, so yes respond
    Engine->>Engine: append bid log entry (proxy A, $115)

    note over Engine,PB: cascade continues until one proxy's next_bid would exceed its max

    Engine->>PB: current_max=$150 (A's last), does B respond?
    PB-->>Engine: yes, next_bid=$155 (<= $180 max)
    Engine->>Engine: append bid log entry (proxy B, $155)

    Engine->>PA: current_max=$155, does A respond?
    PA-->>Engine: no — next_bid $160 > $150 max, mark exhausted_at
    note over Engine: equilibrium reached — proxy A exhausted, proxy B leading at $155

    Engine->>Listing: COMMIT (release FOR UPDATE)
    Engine-->>C: 200 { current_price: 155, you_are_winning: false }

12. Version 3 — production architecture¶

graph TD
    Client -->|bid/proxy-bid| GW[API Gateway]
    GW --> Ingest[Bid Ingestion Service<br/>sharded/partitioned by item_id]
    Ingest -->|single serialized writer per item| Shard1[(Bid log shard 1)]
    Ingest -->|single serialized writer per item| Shard2[(Bid log shard 2)]
    Ingest -->|triggers cascade, same txn| Proxy[Proxy-Bid Engine]
    Proxy -->|reads limits| PBL[(proxy_bid_limits)]
    Ingest -->|accepted bid event| Bus[Event bus]
    Bus --> Notif[Notification Service<br/>outbid alerts]
    Bus --> Price[Live price fan-out<br/>websocket/SSE]
    Sched[Close Scheduler<br/>per-item durable timer] -->|fires at end_time| Ingest
    Ingest -->|final winner + amount| Settle[Payment/Settlement Handoff]

• Bid ingestion sharded by item_id. Every item's bid stream has exactly one serialization point (the shard owning that item), so a hot item's bidding war contends only with itself — it never slows down bids on unrelated items. This is the direct fix for the "500 bids/sec on one item" spike: it's isolated to one shard/partition, sized for that load, while the other 49,999 auctions sit on shards doing almost nothing.
• Proxy-bid engine runs inside the ingestion path's transaction, not as a downstream async consumer — the cascade-resolution problem from the last bottleneck box requires it to see and react to the same serialization point a manual bid uses, or you're back to a race.
• Close scheduler is a durable, per-item timer, not a poller — see the reasoning in Version 2. Cross-reference: this is the same why-not-cron argument as scheduled jobs in other exercises — precision matters when the trigger itself is customer-facing.
• Notification service pushes outbid alerts so a losing bidder has a real chance to respond before close — this is what makes anti-sniping meaningful; extending the clock is pointless if the outbid party never finds out. See Notification System for the delivery-guarantee design (push vs poll, retry, fan-out at scale).
• Settlement handoff on close hands the winning bid off to payment capture — see Payment Processing for the idempotency and hold-capture mechanics; the auction service's job ends at "here is the authoritative winner and amount," not at moving money.

13. Failure analysis¶

14. Consistency considerations¶

• Bid acceptance needs strong consistency and strict ordering, per item — not eventual. The core requirement ("a bid is valid only if higher than the current highest bid at evaluation time") is a linearizability requirement: every accept/reject decision must be made against a value that reflects every previously accepted bid, with no window where two concurrent bids could each be evaluated against a stale price and both get accepted. Eventual consistency here doesn't mean "slightly stale," it means "money changes hands based on a fiction."
• Sharding by item_id is what makes strong-per-item consistency tractable at scale. You don't need one global total order over all bids on the platform — you need one total order per item. Partitioning by item_id gives each item a single serialization point (one shard, one row lock, one queue — whichever mechanism you pick) while different items don't contend with each other at all. This is why 500 bids/sec concentrated on one hot item is a sizing problem for that shard, not a platform-wide bottleneck: the other 49,999 concurrently active auctions are unaffected.
• Everything else can be eventually consistent. The current_price shown to a browsing user, the websocket price feed, the "trending auctions" list — all fine to lag by hundreds of milliseconds. Draw this line explicitly in an interview: strong consistency is expensive and you're paying for it only where the requirement actually demands it (the accept/reject decision), not everywhere the word "bid" appears.
• Read-your-writes for the bidder who just placed a bid — return the accepted state directly in the POST /bids response rather than making the client re-poll GET /price, which might briefly lag behind their own write.

15. Observability¶

Metrics:
  bid_accept_latency_p50/p99{item_id_bucket=hot|normal}
  bid_reject_rate{reason=too_low|closed|duplicate}
  bid_log_write_failures
  active_auctions_extended_count / extensions_used_histogram
  close_scheduler_fire_delta_ms (actual fire time - scheduled end_time)
  proxy_engine_cascade_depth (bids triggered per incoming bid)
  notification_delivery_latency_p99{during=closing_window}
  hot_shard_bids_per_sec (top-K item_ids by shard load)

Alerts:
  close_scheduler_fire_delta_ms > 500ms   (close precision SLO breach)
  bid_accept_latency_p99 > 300ms
  bid_log_write_failures > 0              (durability incident, page immediately)
  proxy_engine_cascade_depth > 20         (possible loop, investigate before it's a fairness incident)
  extensions_used == max_extensions       (auction hit the anti-snipe cap, verify close fires on schedule)

16. Cost analysis¶

Bid log storage (800 MB/day, kept forever, cheap append-only writes):  ~$40/month (grows slowly, retention is an asset not a cost)
Bid ingestion compute (sharded, sized for aggregate + hot-shard headroom): ~$600/month
Durable scheduler (per-item timers, 50K concurrent + churn):           ~$150/month
Notification fan-out (websocket connections, 50K concurrent watchers on hot items): ~$300/month
Postgres (listings + proxy limits, small hot tables):                  ~$250/month primary + replica
Total:                                                                  ~$1,340/month

Cost lever: most of the 50K "live" auctions have near-zero bid traffic —
  autoscale shard capacity per-item based on recent bid rate, not a flat
  per-item reservation, or you're paying hot-item capacity for cold items.

17. Alternative architectures¶

18. Staff Engineer Extensions¶

19. Interview follow-ups¶

1. How would you design the anti-sniping mechanism, and why does it need a cap? Every accepted bid inside the last anti_snipe_window_s extends end_time by anti_snipe_extension_s, up to max_extensions. Without a cap, a determined pair of bidders (or a bug) can make the auction extend indefinitely — bad for planning, bad for the scheduler's assumption that every auction eventually closes. Say the cap explicitly and that it's a product decision, not an implementation detail.
2. How do you prevent shill bidding (seller bidding on their own item to drive up price)? The append-only log is what makes this detectable after the fact — audit for bidder accounts linked to the seller (device fingerprint, payment method overlap, IP) bidding on their own listings; block at the ingestion layer if a bidder_id matches the seller_id outright, and flag suspicious patterns (a low-history account repeatedly bidding just above the reserve then disappearing) for review.
3. What if two bids for the exact same amount arrive "simultaneously"? They can't both be accepted under strict > comparison — the second one to reach the serialization point (row lock / shard writer) is rejected as too_low even if the amounts are equal, since it wasn't higher than the now-current price set by the first. This is why the single-serialization-point design matters: there's no ambiguity, because there's no moment where both requests are evaluated "at the same time" — the lock forces a total order even for ties.
4. How would you test the ordering guarantee itself? Inject synthetic concurrent bid storms (hundreds of near-simultaneous requests with known intended order) against a single item and assert: exactly the bids that were truly higher than the running max at their true evaluation point are accepted, the final price matches the true maximum submitted, and the log's sequence numbers are gap-free and monotonic. Chaos-test the close scheduler by killing the node holding a scheduled timer mid-window and asserting it still fires within SLO after recovery.

Self-Assessment¶

• [ ] I can explain why request-arrival-order and true-bid-intent-order are different things, and why that matters at scale
• [ ] I can justify the append-only bid log over a single mutable "current highest bid" column, with the dispute-resolution/proxy/audit reasoning
• [ ] I can explain why the close mechanism must be a precise timer, not a polling cron, and what "up to N seconds late" actually costs
• [ ] I can describe the anti-sniping extension mechanism and why it needs a hard cap
• [ ] I can explain why sharding by item_id gives strong per-item consistency without a global bottleneck