← 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 list items for sale with time-bound auctions and 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 such as minimum increments and auction deadlines, and notify all participants when the auction ends so the winner can proceed to checkout.
The core engineering challenges are managing bid contention when thousands of users target the same auction simultaneously, pushing real-time bid updates to large viewer audiences, scheduling reliable auction-close events that survive server failures, and coordinating post-auction workflows (payment, notification, seller payout). You will need to reason about optimistic concurrency control, pub/sub fanout, durable timers, and saga-based transaction orchestration.
Based on real interview experiences at Apexx Global, Meta, TikTok, and Adobe, these are the areas interviewers probe most deeply:
Every bid targets the same auction record, creating an intense write hotspot. Interviewers want to see how you serialize concurrent bids efficiently, enforce increment rules, and define deterministic tie-breaking.
Hints to consider:
current_highest_bid, leading_bidder_id, and a version column; accept bids using an UPDATE with a WHERE clause on the version (compare-and-swap)current_highest_bid + min_increment and return the latest auction state so the client can adjustThousands of viewers watching a popular auction need to see bid updates within milliseconds. Broadcasting every change to every viewer is a fan-out scaling problem.
Hints to consider:
Auctions must end at their scheduled time even if the server that created the timer crashes. Many platforms also implement soft-close rules that extend the deadline when a bid arrives near the end.
Hints to consider:
After close, the system must notify the winner, capture payment, inform the seller, and handle failures like payment decline or winner no-show. This is a multi-step workflow requiring saga coordination.
Hints to consider:
Ask whether the platform supports only English auctions (ascending bids) or also Dutch and sealed-bid formats. Confirm scale parameters: concurrent auctions, peak bids per second on a single hot auction, and total viewer count. Clarify soft-close behavior and whether proxy bidding is in scope. Determine if the system handles payment and shipping or only winner declaration.
Sketch the key components: web and mobile clients, an API gateway, a bid ingestion service, Kafka partitioned by auction ID for bid serialization, a bid processor that validates and writes to PostgreSQL with optimistic locking, a WebSocket gateway layer for real-time updates, Redis Pub/Sub for auction-level bid fanout, a scheduler service for auction-close events, and a saga orchestrator for post-auction workflows. Show the bid flow end to end: client submits bid, Kafka serializes it, processor validates against the database, accepted bids are published to Redis, and WebSocket gateways push updates to viewers.
Walk through the critical path. A user submits a bid including the auction ID, amount, and the version they last observed. The bid processor reads the auction row, verifies the amount exceeds the current highest bid plus the minimum increment, and executes an UPDATE with a WHERE clause matching the version. If the update succeeds (one row affected), the bid is accepted: a new bid record is inserted, the auction state is published to Redis, and the client receives a success response. If the version has changed (zero rows affected), the processor returns the latest auction state and the client retries. Explain how Kafka partitioning by auction ID ensures bids for the same auction arrive in order at the processor, reducing database contention.
Cover auction-close scheduling: durable jobs with at-least-once delivery and idempotent execution. Discuss fanout scaling: Redis Pub/Sub per auction, tiered relay servers for mega-auctions, and delta updates to reduce bandwidth. Address the post-auction saga: payment authorization, winner notification, seller payout, and compensation for payment failures. Mention monitoring: track bid acceptance latency, rejection rate, WebSocket connection count, scheduler lag, and payment success rate. Discuss scaling: shard PostgreSQL by auction ID, scale WebSocket gateways horizontally, and add Kafka partitions as volume grows.