Design an Online Auction

Each phase is what the interviewer expects you to do and say. Concrete steps, not topic hints. The diagrams are what you sketch on the board.

1. 1

   Clarify Requirements and Scale

   5 min

   GoalPin the bid concurrency model, the broadcast latency target, and the settlement guarantee. The whole design pivots on per-auction serialization plus effectively-once settlement, so name both up front.

   Do & Say

   1. ASK·1ASK: “what happens when two users bid the same amount at the same instant? Accept both? Reject both? Pick one deterministically?” Walk to “one wins, the other gets OUTBID with the new price”. That commits you to per-auction serialization.
   2. SAY·2Lock the broadcast SLO: “watchers see new price within 200ms of acceptance, p99 regional”. That rules out polling and forces “WebSocket + sharded Pub/Sub”. Write “200ms p99” in the corner.
   3. SAY·3Pin the settlement guarantee: “effectively-once”. After retries: “exactly one SOLD row per auction”, “exactly one captured charge at the payment provider”. Not exactly-once across the payment boundary (Stripe is a separate authority), but effectively-once on our side.
   4. SAY·4Get the numbers on the board: “10M active auctions”, “50K bids/sec peak”, “1.7K average”, “1M concurrent WebSocket watchers”. Hot auctions take “100-500 bids/sec in the final minute”. That hot-auction rate is the per-partition ceiling. Write “50K total / 500 hot” in the corner.
   5. SAY·5Define scope. In scope: “English auction”, “anti-sniping”, “proxy bidding”, “settlement”. Stretch: “Dutch”, “sealed-bid”. Out of scope: “seller payouts”, “KYC”, “fraud ML”, “search ranking”.

   Interviewer is grading: You name per-auction serialization (not global) as the concurrency model. You separate the per-auction hot rate from the aggregate rate. Effectively-once vs exactly-once distinction lands early.

2. 2

   API and Data Model

   5 min

   GoalOne bid endpoint with the load-bearing field (expected_price), the auction state hash in Valkey, and the immutable bids table in Postgres. Get the optimistic-concurrency precondition on the board now.

   Do & Say

   1. WRITE·1Write the bid endpoint: “POST /auctions/{id}/bids {amount, expected_price, idempotency_key}”. Returns “202 with bid_id + QUEUED”. Terminal result rides the WebSocket as “bid_result {ACCEPTED, REJECTED with reason, current_price}”.
   2. SAY·2Call out the load-bearing field: “expected_price is what the client thinks current_price is”. CAS accepts only if “expected_price matches server current_price”. Without it, a client at $100 bidding $105 against a server at $108 gets a misleading “TOO_LOW”. With it, “STALE_EXPECTED_PRICE” fires and the UI refreshes.
   3. DRAW·3Sketch the Valkey auction state hash: “HSET auction:{id}” with fields “status”, “current_price”, “high_bidder”, “current_end_time”, “sequence_num”, “min_increment”. That hash is the CAS target. Lua script reads and updates atomically under Valkey's single-threaded execution.
   4. DRAW·4Sketch the Postgres bids table: “auction_id (partition key)”, “bidder_id”, “amount”, “sequence_num”, “status”, “idempotency_key”, “created_at”. Partial unique index on “(auction_id, sequence_num) WHERE status = ACCEPTED” dedupes Kafka redelivery and keeps sequence_num gap-free among accepted bids.
   5. SAY·5Mention the proxy_bids table: “auction_id”, “bidder_id”, “max_amount”, “is_active”. The proxy resolver reads this on every “bids.accepted” to decide if an auto-bid fires. One-line mention; deep dive later.

   Interviewer is grading: expected_price appears in the request body, not as an afterthought. The partial unique index on accepted bids is named with its dedup purpose. Auction state lives in Valkey for CAS, Postgres for truth.

3. 3

   High-Level Design (draw the four flows)

   10 min

   GoalOne diagram with four flows visible: Submit, Process, Broadcast, Settle. Correctness lives in two specific places (the Valkey CAS and the settlement fencing token); make those two points stand out.

   Draw on the board
   Do & Say

   1. DRAW·1Draw four lanes left to right: “Submit”, “Process”, “Broadcast”, “Settle”. Correctness lives in two places only: “Valkey CAS decides who wins each bid” and “fencing token on the auction row decides whose settlement commits”. Everything else is delivery and fan-out.
   2. SAY·2Walk the Submit lane: “API does auth”, “per-user rate limits (10/sec, 200/min)”, “fast reject if status != ACTIVE or now > current_end_time”, “produce to Kafka partitioned by auction_id”. The API does NOT validate amount. That check belongs inside the CAS, under serialization.
   3. SAY·3Walk the Process lane: “one consumer per Kafka partition”, “auction_id as partition key keeps all bids for an auction in arrival order”. Lua CAS does: “read state”, “check expected_price”, “check amount >= current + min_increment”, “INCR sequence_num”, “update state”, “return”. Atomic under Valkey's event loop.
   4. SAY·4Walk the Broadcast lane: “bids.accepted → fan-out service”, “SPUBLISH on Valkey sharded Pub/Sub”, “each WS gateway SSUBSCRIBEs to channels for its watched auctions”, “writes frames to local watchers”. Plain PUBLISH broadcasts to every node; SPUBLISH stays on the shard owning “auction:{id}”.
   5. SAY·5Walk the Settle lane: “Flink keyed timer per auction”, “on firing → INCR fence:auction:{id}”, “read winning bid”, “conditional UPDATE on auctions guarded by fencing token”, “capture with Idempotency-Key = settle-{auction_id} (stable across retries)”.

   Interviewer is grading: Four flows clearly separated. The two correctness anchors (CAS and fencing) are named with their roles, not generic 'we use Redis'. SPUBLISH vs PUBLISH distinction lands. auction_id is the partition key, not bid_id.

4. 4

   Deep Dive: CAS, Fencing, and Proxy Bidding

   15 min

   GoalThree sub-dives. The Lua CAS step by step. The fencing-token settlement trap (idempotency key must be stable). Proxy bidding's jump-to-price algorithm so two proxies don't ratchet up by $1 forever.

   Draw on the board
   Do & Say

   1. SAY·1Pivot to the CAS script. Walk the seven steps: “SET bid_result:{bid_id} NX (dedup Kafka redelivery)”, “check status/end_time (else AUCTION_CLOSED)”, “check expected_price==current_price (else STALE_EXPECTED_PRICE)”, “check amount>=current+min_increment (else BID_TOO_LOW)”, “INCR sequence_num + update current_price + high_bidder”, “extend end_time if in anti-snipe window”, “cache result”.
   2. SAY·2Defend optimistic concurrency: “SELECT FOR UPDATE on the auction row serializes via DB row lock”, “at 500 bids/sec on one hot auction the lock queue grows, pool saturates, p99 spikes to seconds”. Valkey CAS is sub-ms with no lock manager. Serialization is implicit in the single-threaded event loop.
   3. SAY·3Address auctions.current_price not updating per bid: “current_price in Postgres is a hint, not authoritative”. Authoritative is “MAX(amount) FROM bids WHERE auction_id=? AND status=ACCEPTED”. Updating one row 500 times/sec creates MVCC bloat and a CDC event flood. The bids table is append-only, which Postgres handles cleanly.
   4. SAY·4Pivot to settlement. Walk the duplicate scenario: “Pod A grabs fence 42”, “writes SOLD”, “calls Stripe with key settle-abc-42”, “captures $240”, “pod evicted before final UPDATE”. Then: “Kafka redelivers”, “Pod B grabs fence 43”, “UPDATE succeeds since 42<43”, “calls Stripe with key settle-abc-43 (new key)”, “Stripe captures again”. Double charge.
   5. SAY·5Name the fix: “idempotency key must be tied to the auction, not the attempt”. Use “Idempotency-Key = settle-{auction_id}” stable across retries. Stripe returns the original capture on the second call. The “fencing token orders writes”, the “idempotency key orders side effects”. Independent dimensions.
   6. SAY·6Pivot to anti-sniping: “bid arrives within anti_snipe_seconds (e.g., 30s) of end_time”, “extend by anti_snipe_extend (e.g., 120s)”, “atomic with bid acceptance in the same Lua script”, “extension relative to current end_time, not original”. We emit “auctions.end_time_changed” so Flink re-arms the keyed timer in place.
   7. SAY·7Handle the infinite-extension attack: “bot bidding every 29 seconds keeps the auction open forever”. Two caps: “maximum total extension (e.g., 30 min from original end)” and “per-bidder extension quota”. Once hit, the script extends silently or not at all, and the auction closes on schedule.
   8. SAY·8Pivot to proxy bidding: “two proxies with maxes $200 and $500”. Naive ratchets by min_increment, hundreds of penny bids until one caps. Fix: “jump_price = min(winner.max, runner_up.max + min_increment)” and submit one bid. For $200/$500, “jump_price = $201”. One bid ends the cascade.
   9. WATCH·9Be ready for the timer-service question: “10M timers in Flink keyed state by auction_id”, “checkpointed to S3 every 10s”, “on JobManager failure new leader recovers and replays timers whose deadlines passed during downtime”. setTimeout dies on pod restart, pg_cron doesn't scale to 10M moving deadlines.

   Interviewer is grading: You can walk the CAS in seven discrete steps. You name the idempotency-key-in-the-key bug as the subtle trap of settlement design, not as a footnote. The proxy-bid jump-to-price math is on the board with a worked example.

5. 5

   Trade-offs, Risks, and Wrap-up

   5 min

   GoalTwo deliberate trade-offs (regional pinning, effectively-once at the payment boundary), name the recoverable failure modes, and close with one sentence that summarizes the four-flow design.

   Do & Say

   1. SAY·1Trade-off one: “auctions pinned to one region for their lifetime”, “bid writes not active-active across regions”, “cross-region failover is a 5-10 min manual operation”. We accept that for sub-200ms regional latency. Going active-active would require global Paxos on every bid, which doesn't pencil at 50K/sec.
   2. SAY·2Trade-off two: “effectively-once over exactly-once”. Exactly-once across the payment boundary is impossible because Stripe is an independent system with its own retry semantics. We guarantee “one SOLD row”, “one captured-from-our-side”, and “a stable idempotency key so Stripe returns the original capture on retry”. That's the contract.
   3. SAY·3Name recoverable failure modes: “crash after fence INCR pre-PG-write → next attempt gets higher token, same outcome”, “crash after PG write pre-payment → next sees INITIATED, sends payment with same idempotency key, updates”, “crash after payment pre-Kafka → next re-reads, sees PAYMENT_CAPTURED, emits”. Every stage idempotent.
   4. SAY·4Mention Valkey loss: “Postgres is source of truth”. If Valkey dies, hydrate a new instance from Postgres (“current_price”, “high_bidder”, “sequence_num” all derivable via MAX on bids). Hydrate takes minutes for 10M auctions. During hydrate, new bids return 503, watchers stay on last cached state.
   5. SAY·5Mention seller payouts in one line: “settlement is only half the lifecycle, other half is seller_payouts”, “held during chargeback window (7-30 days)”, “disbursed via Stripe Connect transfers.create”, “idempotency key payout-{auction_id}”. Out of scope today but I can come back to it.
   6. SAY·6Close in one breath: “four flows”, “Submit produces partitioned by auction_id”, “Process serializes via per-partition consumer + Valkey CAS”, “Broadcast uses sharded Pub/Sub”, “Settle uses fencing token + stable idempotency key for effectively-once”. Correctness lives in “CAS and the fence”. Everything else is delivery.
   7. SAY·7If there's time, offer: “Dutch auction price-ticks”, “sealed-bid encryption”, “retraction mid-settlement”, or “bidder risk tiers + payment-hold sizing”.

   Interviewer is grading: Regional pinning named as a deliberate choice. Effectively-once defined precisely (not 'kinda exactly-once'). The closing sentence ties four flows and the two correctness anchors together in under 30 seconds.

Questions an interviewer is likely to ask after your walkthrough. Rehearse the short answer.

1. Why optimistic CAS instead of SELECT FOR UPDATE on the auction row?
2. What's the subtle settlement double-charge bug?
3. How does anti-sniping not extend an auction forever?
4. Why proxy jump-to-price instead of naive ratcheting?
5. What if Valkey vanishes mid-auction?
6. What does expected_price prevent?
7. Why SPUBLISH and not PUBLISH on a clustered Valkey?
8. How does the timer service handle 10M live deadlines?