← Back to companies
[ OK ] Loaded —
[ INFO ]
$ cd
$ ls -lt
01
02
03
04
05
$ ls -lt
01
02
03
04
05
user@intervues:~/$
Design an online auction platform where users can list items for sale, set time-bound auctions, and let other users compete by placing increasingly higher bids until the auction closes. The system must display the current highest bid and leading bidder in real time, enforce bidding rules (minimum increment, auction end time), and notify participants when the auction concludes. The winner proceeds to checkout and payment.
The core engineering challenges are handling bid contention on popular auctions where thousands of users submit bids within seconds, delivering sub-second odds updates to all viewers, scheduling reliable auction-close events, and orchestrating post-auction workflows (winner notification, payment capture, seller payout). You will need to reason about optimistic concurrency, real-time fanout, durable timers, and multi-step transactional workflows.
Based on real interview experiences at Adobe, Meta, Apexx Global, and TikTok, these are the areas interviewers probe most deeply:
All bidders target the same auction record, creating a classic write hotspot. Interviewers want to see how you serialize concurrent bids without collapsing throughput, and how you define deterministic tie-breaking rules.
Hints to consider:
current_highest_bid and a version column; use optimistic concurrency (compare-and-swap on version) to accept or reject each bid atomicallycurrent_highest_bid + min_increment, returning the latest state so the client can retryViewers watching an auction expect to see bid updates within a fraction of a second. Broadcasting every update to every connected client on a popular auction is a fan-out challenge.
Hints to consider:
Auctions must close precisely at the scheduled time, even if the server that originally scheduled the timer has crashed. Many auctions also implement soft-close rules (extending the deadline if a bid arrives in the final seconds).
Hints to consider:
After an auction closes, the system must notify the winner, initiate payment capture, notify the seller, and handle edge cases like payment failure or winner no-show. This is a multi-step, failure-prone workflow.
Hints to consider:
Ask whether the platform supports English auctions only (ascending bids) or also Dutch or sealed-bid formats. Confirm the scale: how many concurrent auctions, peak bids per second on a single auction, and total viewer count. Clarify soft-close rules and whether proxy bidding (automatic incremental bids up to a user's maximum) is in scope. Determine if the system handles payment and shipping or stops at winner declaration.
Sketch the main components: web and mobile clients, an API gateway, a bid ingestion service, Kafka partitioned by auction ID for bid serialization, a bid processor that applies concurrency control against PostgreSQL, a WebSocket gateway layer for real-time updates, Redis Pub/Sub for bid fanout, a scheduler service for auction-close events, and a post-auction workflow orchestrator. Show the bid flow: client submits bid to API, bid lands in Kafka, processor validates and writes to PostgreSQL with optimistic locking, accepted bid published to Redis Pub/Sub, edge servers push to viewers.
Walk through the critical path. A user submits a bid with the auction ID, amount, and the version of the auction state they last saw. The bid processor reads the current auction row, verifies the amount exceeds current_highest_bid + min_increment, and performs an UPDATE with a WHERE clause on the version column. If the row is updated (version matched), the bid is accepted, a new bid record is inserted, and the accepted-bid event is published. If the version has advanced (another bid was accepted in between), the processor returns the latest state and the client can retry. Discuss how partitioning Kafka by auction ID ensures bids for the same auction are processed sequentially, reducing contention on the database.
Cover auction-close scheduling: durable jobs stored in the database with at-least-once delivery and idempotent execution. Discuss real-time fanout: Redis Pub/Sub channels per auction, with tiered relay servers for viral auctions. Address the post-auction saga: payment authorization, winner notification, seller notification, and compensation for payment failures. Mention monitoring: track bid acceptance latency, rejection rate, WebSocket connection count, auction-close job lag, and payment success rate. Discuss scaling: shard PostgreSQL by auction ID, scale WebSocket gateways horizontally, and add Kafka partitions as auction volume grows.