hibranwar
Course → Module 8: Real-World Case Studies II

Online Auction Platform

Session 8.5 · ~5 min read

The Problem

An auction for a rare guitar ends at 3:00:00 PM. At 2:59:58, a new bid arrives. This bid is valid. But it was timed to prevent other bidders from responding. This is bid sniping, and it undermines the auction's purpose of discovering the true market price through competitive bidding.

An online auction platform must solve several problems simultaneously: strict ordering of bids (the highest valid bid wins, always), protection against last-second sniping, detection of fraudulent bid patterns, and real-time notification to all participants. Each of these has distinct consistency and latency requirements.

Auction Lifecycle

Every auction follows a state machine. The transitions must be strictly controlled because each state change has financial and legal consequences.

stateDiagram-v2 [*] --> Draft : Seller creates listing Draft --> Scheduled : Listing approved Scheduled --> Active : Start time reached Active --> Active : New bid received Active --> Extended : Bid in final window (anti-snipe) Extended --> Active : Extension period elapses, no new bids Extended --> Extended : Another bid during extension Active --> Ended : End time reached, no final-window bids Extended --> Ended : Extension elapses with no new bids Ended --> Sold : Payment confirmed Ended --> Unsold : Reserve not met / no bids Sold --> [*] Unsold --> [*]

The transition from Active to Extended is the anti-sniping mechanism. The transition from Ended to Sold requires payment confirmation within a deadline. If the winning bidder does not pay, the platform may offer the item to the second-highest bidder.

Strict Bid Ordering

The fundamental requirement of an auction is that the highest valid bid wins. In a distributed system, this is harder than it sounds. Two bids arrive at two different servers at nearly the same time. Without a single source of truth for bid order, the system could accept both, or accept the wrong one.

The standard solution is a single-writer pattern per auction. All bids for a given auction route to one designated partition (shard). Within that partition, bids are processed sequentially. There is no concurrent write to the same auction's bid history.

This is a deliberate trade-off. By funneling all bids for one auction through a single writer, you sacrifice write throughput on that auction in exchange for absolute ordering guarantees. For most auctions, this is fine. Even the most popular auctions receive at most a few hundred bids per minute, not thousands per second.

sequenceDiagram participant B1 as Bidder 1 participant B2 as Bidder 2 participant LB as Load Balancer participant BP as Bid Processor
(Auction #4821 Partition) participant DB as Auction DB participant N as Notification Service B1->>LB: Bid $450 on Auction #4821 B2->>LB: Bid $475 on Auction #4821 LB->>BP: Route both to partition for #4821 Note over BP: Process sequentially BP->>DB: Read current high bid ($400) BP->>DB: Validate & accept $450 BP->>N: Notify all: new high bid $450 N->>B2: You've been outbid ($450) BP->>DB: Read current high bid ($450) BP->>DB: Validate & accept $475 BP->>N: Notify all: new high bid $475 N->>B1: You've been outbid ($475)

Routing is deterministic. The auction ID is hashed to select the partition. Every bid for auction #4821 goes to the same processor, regardless of which server receives the HTTP request. This guarantees a total order on all bids for that auction.

Anti-Sniping: Time Extension

Bid sniping is placing a bid in the final seconds of an auction, leaving no time for other bidders to respond. On platforms without protection, sniping tools automatically submit bids 1 to 3 seconds before the auction ends.

The standard countermeasure is a time extension. If a bid arrives within the final N minutes (commonly 2 to 5 minutes) of an auction, the auction deadline extends by N minutes from the time of that bid. This extension can repeat: if another bid arrives during the extension, the clock extends again.

The auction ends only when the extension period elapses with no new bids. This recreates the dynamics of a live auction, where bidding continues as long as someone raises their hand.

Time Event Auction End Time
2:55:00 PM Auction scheduled to end at 3:00 PM 3:00:00 PM
2:59:58 PM Bid received (within 5-minute window) 3:04:58 PM (extended +5 min)
3:03:30 PM Counter-bid received (within window) 3:08:30 PM (extended again)
3:08:30 PM No bids during extension Auction ends. Last bidder wins.

The extension window size is a design decision. Too short (30 seconds) and snipers can still time their bids to prevent response. Too long (15 minutes) and auctions drag on unnecessarily. Most platforms settle on 2 to 5 minutes.

Consistency Requirements by Operation

Not every operation in an auction system requires the same consistency guarantees. Over-engineering consistency where it is not needed wastes resources. Under-engineering it where it is needed causes disputes.

Operation Consistency Requirement Rationale
Place a bid Strong (linearizable) Bid ordering must be globally agreed. No two bids can appear to have different orderings on different nodes.
View current high bid Eventual (seconds stale is acceptable) Displaying a bid that is 2 seconds old does not cause financial harm. Bidders will see the updated value shortly.
Auction end determination Strong (linearizable) All nodes must agree on whether the auction is still active. A bid accepted after the auction ended is a legal problem.
Outbid notification At-least-once delivery Missing a notification is a poor experience. Duplicate notifications are tolerable.
Bid history display Eventual The full bid history is informational. Slight delays in display are acceptable.
Payment processing Exactly-once (idempotent) Charging a winner twice is unacceptable. Payment must be idempotent.

Counterfeit Bid Detection

Shill bidding is when a seller (or an accomplice) places fake bids on their own item to drive the price up. The winning bidder pays an inflated price. Detection uses pattern analysis:

Detection typically runs as an asynchronous pipeline. Bids are accepted in real time (you cannot block a bid while running a fraud model), but flagged bids trigger review. If fraud is confirmed, the auction is voided and the seller faces penalties.

Outbid Notifications

When a new bid arrives, every previous bidder who is still in the running must be notified. This is a fan-out problem. A popular auction with 500 bidders means each new bid triggers 499 notifications.

Notifications must be delivered reliably but do not need to be synchronous with bid processing. The bid processor publishes an event to a message queue. A notification consumer reads the event, looks up all previous bidders, and sends push notifications, emails, or SMS based on each user's preferences. If delivery fails, the message is retried.

The at-least-once delivery guarantee means a user might receive two "you've been outbid" notifications for the same bid. This is preferable to the alternative: missing the notification entirely and losing the auction without knowing.

Further Reading

Assignment

An auction for a collectible item is scheduled to end at 3:00:00 PM. The anti-sniping window is 5 minutes. A bid of $500 arrives at 2:59:58 PM.

  1. What is the new auction end time? If a counter-bid arrives at 3:04:00 PM, what happens?
  2. The platform runs on 5 servers across 2 data centers. A bid arrives at Server A in Data Center 1. Another bid (higher) arrives at Server B in Data Center 2, 50ms later. How does the system guarantee that both data centers agree on which bid was first? What pattern ensures this?
  3. A seller creates a second account and bids on their own item to raise the price from $200 to $350. What signals would a fraud detection system look for? Which of those signals could also appear in legitimate bidding?
  4. The auction has 300 active bidders. A new bid triggers 299 outbid notifications. If the notification service is momentarily down, what delivery guarantee prevents missed notifications? What is the user-facing consequence of this guarantee?