An online auction platform allows sellers to list items and buyers to compete for them by placing bids. Although the user experience appears simple, the underlying system must process concurrent bids, deliver real-time updates, close auctions at precise times, and select winners without ambiguity.
Designing an auction platform is a useful system design interview problem because different parts of the system require different guarantees. Search and product images can be eventually consistent, while accepting bids and choosing a winner require strict correctness.
In this post, we’ll design a scalable online auction platform and explore the architecture, bidding workflow, consistency model, and most important failure cases.
A system design interview may begin with the following prompt:
Design an online auction platform like eBay.
A complete marketplace could include fixed-price listings, advertising, seller ratings, disputes, international shipping, tax calculation, recommendations, and many other features.
For this design, we will focus on timed auctions. Sellers can create listings containing a description, images, starting price, and closing time. Buyers can browse auctions, place bids, receive live updates, and pay if they win.
The system must provide a clear answer to several important questions. Was a bid accepted? What was the order of two bids submitted at nearly the same time? Which bid was highest when the auction closed? Can a retry accidentally create the same bid twice?
Correctly answering these questions is the heart of the design.
The main functional requirements cover the auction lifecycle.
A seller must be able to create a listing, upload images, set a starting price, define a minimum bid increment, and choose when the auction will end. Buyers should be able to browse and search for listings, view the current price, place bids, and watch auctions they are interested in.
When a bid is accepted, other viewers should receive an update with minimal delay. When the auction ends, the system must stop accepting bids, determine the winner, create an order, and notify both the buyer and seller.
Users should also be able to view an auction’s bid history. Public history may hide bidder identities, while the platform retains the complete information for auditing and dispute resolution.
Advanced capabilities such as fixed-price purchases, multiple-item auctions, returns, shipping calculations, and advertising can be left outside the initial scope.
The non-functional requirements are particularly important. Bid processing must be strongly consistent within an auction. The platform should be highly available, but it must not accept a bid if it cannot safely determine whether that bid is valid.
Product discovery should remain fast during periods of heavy traffic. Popular auctions may attract large numbers of viewers and last-second bids, so the design must handle both high overall traffic and extreme concentration on a single listing.
The first workflow is creating an auction. The seller enters the listing details, uploads media, and specifies the auction rules. The system validates the request and schedules the auction to open and close at the appropriate times.
The second workflow is product discovery. Buyers browse categories, search for keywords, open auction pages, and add interesting listings to a watchlist. This workload is read-heavy and can make extensive use of caching, search indexes, and a content delivery network.
The most important workflow is bidding. A buyer submits an amount, the system validates the auction state and bid rules, and then either accepts or rejects the bid. Accepted bids update the current auction state and trigger real-time messages to connected clients.
The final workflow is auction settlement. At the closing time, the platform prevents further bids, selects the winning bidder, creates an order, and begins the payment process.
These workflows have different consistency requirements. Search results can briefly show an old price, but the bidding service must use the authoritative auction state.
Suppose the platform supports 20 million registered users and five million daily active users. If each active user views 30 auction or search pages per day, the system handles approximately 150 million read requests each day.
The average request rate is manageable, but traffic will be uneven. A limited-edition product or celebrity auction could attract hundreds of thousands of viewers at once.
Assume the platform processes ten million bids per day. The average is approximately 115 bids per second, but many bids will arrive during the final seconds of popular auctions. Peak traffic could reach tens of thousands of bids per second across the platform.
The distribution matters as much as the total. Ten thousand bids spread across ten thousand auctions can be processed in parallel. Ten thousand bids targeting one auction must be placed into one authoritative order.
This hot-auction problem influences how bids are partitioned, stored, and processed.
Clients access the platform through an API Gateway.
A simplified public API might include:
POST /auctions
GET /auctions/{auctionId}
GET /auctions/{auctionId}/bids
POST /auctions/{auctionId}/bids
POST /auctions/{auctionId}/watch
GET /search?q={query}
GET /users/{userId}/bids
GET /users/{userId}/winsThe bid request should include an idempotency key:
{
"amount": 275.00,
"currency": "GBP",
"idempotencyKey": "55047b60-52a3-4c0b-a642-90ef844f6505"
}The response should clearly state whether the bid was accepted and return the authoritative auction state:
{
"accepted": true,
"bidId": "bid_891257",
"currentPrice": 275.00,
"auctionVersion": 148,
"endsAt": "2026-09-18T19:30:00Z"
}The main data entities are users, sellers, auctions, auction media, bids, watchlist entries, orders, payments, and notifications.
An auction contains its seller, status, start and end times, starting price, minimum increment, current winning bid, current winner, and version number. Bid records are immutable and contain the auction, bidder, submitted amount, server timestamp, idempotency key, and processing result.
The current auction state and full bid history may be stored separately. The current state is accessed frequently during bidding, while the immutable history is retained for auditing and dispute resolution.
The platform uses a collection of independently scalable services:
Web App ──────────┐
Mobile App ───────┼──→ API Gateway
Seller Portal ────┘ │
├──→ Identity Service
├──→ Auction Service
├──→ Bid Service
├──→ Search Service
├──→ Watchlist Service
├──→ Order Service
└──→ Payment Service
│
Message Broker
│
┌────────────┼────────────┐
↓ ↓ ↓
Real-Time Notification Analytics
Service Service PipelineBuyers can access the platform through a web application or mobile application. Sellers may use the same clients or a dedicated seller portal for creating listings and managing completed auctions.
All requests pass through the API Gateway. The gateway validates authentication tokens, applies rate limits, routes requests, and records usage information.
The gateway can combine information for read-heavy pages, but it should not contain bidding rules. Bid validation and auction state transitions belong inside the authoritative Bid and Auction services.
Images and other static media are delivered through a CDN. This keeps large files away from the application services and improves loading times for users in different regions.
The Auction Service manages listing details and the auction lifecycle. It owns titles, descriptions, categories, prices, start times, end times, and status changes.
Auction details change relatively infrequently and can be cached. The current winning price may also be cached for display, but the cache is not authoritative when a new bid is evaluated.
The Bid Service is responsible for accepting or rejecting bids. It validates the auction status, closing time, current price, minimum increment, bidder eligibility, currency, and idempotency key.
All bids for the same auction must be processed in a deterministic order. The service partitions traffic by auction identifier so that bids for different auctions can be processed independently.
The accepted bid is written to durable storage in the same transaction that updates the auction’s current state.
The Search Service maintains an index designed for keyword queries, categories, filters, and sorting. It receives listing changes asynchronously from the Auction Service.
Search results may briefly display an old price or status. When the buyer opens an auction page or submits a bid, the platform retrieves the latest authoritative state.
The Real-Time Service maintains WebSocket or server-sent event connections with clients viewing active auctions.
After a bid has been committed, the Bid Service publishes an event. The Real-Time Service distributes the new price and auction version to connected viewers.
These updates improve the user experience, but they do not determine whether a bid was accepted. The direct response from the Bid Service remains authoritative.
When an auction closes successfully, the Order Service creates an order for the winner and seller. The Payment Service then manages payment through an external provider.
Payment happens after the winner has been determined. A temporary payment failure should not change the historical outcome of the auction, although the platform may give the winner a limited period to complete payment before applying its business rules.
The platform uses synchronous requests when the user needs an immediate answer. Placing a bid is synchronous because the buyer must learn whether it was accepted.
Asynchronous events are used after an important state change has been committed. An accepted bid can publish a BidAccepted event, while a closed auction can publish an AuctionClosed event.
The Real-Time Service, Notification Service, analytics pipeline, and fraud systems consume these events independently. The bidding response does not need to wait for every connected viewer to receive an update.
The transactional outbox pattern can ensure that committed bids produce events reliably. The bid and an outgoing event are stored in the same database transaction. A background publisher then sends the event to the message broker.
Without this protection, the service could commit a bid and crash before announcing it to downstream systems.
The most important parts of the design are bid ordering, concurrency control, auction closing, and real-time delivery.
When the Bid Service receives a request, it first checks the idempotency key. If the same request has already been processed, the service returns the original result instead of creating another bid.
The service then loads the authoritative auction state. It verifies that the auction is active and compares the server’s current time with the closing time. Client timestamps are never trusted because a user could alter their device clock or delay a request intentionally.
The bid amount must meet the minimum required value. The bidder must also be eligible to participate and must not be the seller.
If the bid is valid, the service creates an immutable bid record and updates the auction’s current winner, price, and version. These changes occur atomically.
Only after the transaction commits does the system publish the accepted bid to other services and connected clients.
Two buyers may submit the same amount at almost exactly the same time. The system needs a deterministic rule for choosing which bid came first.
One approach is to use a database transaction with a row-level lock on the auction. Each bid waits for exclusive access, reads the latest state, and updates it before releasing the lock.
This is relatively simple and provides strong consistency. It works well until a highly popular auction produces more traffic than one database row can process efficiently.
A larger system can route all bid commands for one auction to the same logical partition. A leader for that partition appends bids to a durable ordered log and processes them sequentially.
Different auctions are distributed across many partitions and processed in parallel. One auction remains serialised because its bids must share one authoritative order.
No architecture can completely remove this limit while retaining strict ordering. A single extremely popular auction is an inherently sequential workload.
An alternative to locking is optimistic concurrency.
Each auction has a version number. The Bid Service reads the current state and attempts a conditional update that succeeds only if the version remains unchanged:
UPDATE auction
SET current_price = 275,
current_bid_id = 'bid_891257',
version = 149
WHERE auction_id = 'auction_123'
AND version = 148
AND status = 'ACTIVE'If another bid updates the auction first, the conditional write fails. The service reloads the current state and validates the bid again.
This approach works well when conflicts are uncommon. During the final seconds of a popular auction, repeated retries may create heavy contention. Partition-based serial processing can provide more predictable performance for those hot auctions.
Closing an auction requires more than a scheduled job that runs at the expected end time.
The authoritative rule is that a bid is valid only if the Bid Service accepts it while the auction is active and before its stored closing time. The server’s processing time determines whether the bid arrived in time, not the time shown on the client.
A scheduler can organise auctions into time buckets and send a close command when their end time arrives. The Auction Service then performs an atomic state transition from ACTIVE to CLOSED.
The transition succeeds only if the auction is still active and its end time has passed. This makes the operation safe to retry.
The Bid Service and closing process must use the same source of truth. Once the close transition commits, later bids are rejected. If a bid commits first, that bid becomes part of the final state before the auction closes.
After closing, the platform publishes an event containing the winning bid. The Order Service consumes it and creates the order.
Some auction platforms use a fixed closing time. Others apply an anti-sniping rule that extends the auction if a bid arrives during its final seconds.
This is a business decision rather than a purely technical one.
If extensions are supported, an accepted bid can atomically update both the current price and closing time. For example, a bid placed during the final two minutes might extend the auction by another two minutes.
The updated closing time must be included in the bid event so that schedulers, clients, and notification systems receive the change.
A more advanced platform may allow buyers to submit the maximum amount they are willing to pay. The system automatically increases the visible bid only enough to remain ahead of competing bidders.
Maximum values must remain private. The Bid Service compares the leading maximum with the new bidder’s maximum and calculates the visible price according to the minimum increment.
If two users submit the same maximum, the earlier accepted bid remains ahead. This makes deterministic bid ordering especially important.
Proxy bidding adds complexity but does not fundamentally change the architecture. The bidding engine still serialises commands for each auction and stores the resulting state atomically.
WebSockets are well suited to active auction pages because the server can push new prices without requiring constant client polling.
When a user opens an auction, the client retrieves the current state through the normal API and then subscribes to a real-time channel for that auction.
Each event includes the auction version. If a client receives version 151 after version 149, it knows an update was missed and can refresh the current state through the API.
The Real-Time Service does not need to retain every connection on one server. Connections can be distributed across many instances, with a message broker or pub-sub layer delivering auction events to the instances that have interested viewers.
The system should limit the number of channels and connections available to each user. It should also avoid broadcasting private bid amounts or personal bidder information.
Auction descriptions, seller information, and media references can be cached because they change infrequently. CDN caching can handle most image traffic.
The current price and closing time may also be cached for read-only display, but bid processing must never rely exclusively on the cache. A delayed cache update could otherwise cause the service to accept an invalid bid.
Popular auctions create hot cache keys and hot bid partitions. Read traffic can be distributed by replicating cached state and publishing updates through the real-time system.
Write traffic is harder to distribute because bids require ordering. The platform can detect unusually popular auctions and move them to dedicated bid-processing partitions with additional CPU, memory, and network capacity.
Admission control may also be necessary. If one auction receives more bids than can be processed before its closing time, the service should reject excess requests clearly rather than allowing an unbounded queue to grow.
Bid requests should use idempotency keys so that retries cannot create duplicate accepted bids. The idempotency record and bid result should be stored atomically.
Clients need short timeouts, but a timeout does not necessarily mean that a bid was rejected. The request may have committed while the response was lost. The client should retry with the same idempotency key or request the result before submitting a different bid.
The bidding database should be replicated and support automatic failover. During an uncertain leadership change, the platform may briefly pause bidding for affected auctions rather than risk two leaders accepting conflicting bids.
Message consumers should be idempotent because an accepted-bid or auction-closed event may be delivered more than once. The Order Service must not create two orders if it receives the same closing event twice.
If the Real-Time Service fails, bidding can continue. Clients can reconnect and retrieve the latest state through the normal API. This is an example of graceful degradation: live animation may stop temporarily, but the authoritative auction remains correct.
The API Gateway authenticates users and applies rate limits, while the Bid Service verifies that the bidder is permitted to participate.
Authorisation must be checked for every sensitive operation. Knowing an auction or bid identifier does not give a user permission to modify it.
The platform should protect against bots, denial-of-service attacks, fake accounts, and automated bid manipulation. Rate limits can be applied by account, device, IP address, and auction, although they must be designed carefully to avoid blocking legitimate users sharing a network.
Fraud systems can analyse unusual bidding patterns, rapid account creation, payment failures, and relationships between bidders and sellers. Shill bidding, in which a seller or associate artificially increases the price, may require both automated detection and human investigation.
Complete bid histories should be retained for auditing. Accepted and rejected bids, timestamps, account information, auction versions, and processing decisions may all be relevant during a dispute.
Payment details should be handled through a trusted payment provider wherever possible. Sensitive information must be encrypted and access to administrative tools should be carefully controlled.
Technical monitoring should cover request latency, bid acceptance rates, database contention, message queue depth, WebSocket connections, cache hit rates, and service error rates.
Auction-specific measurements are equally important. The platform should track bids processed per auction, bid-processing delay, duplicate requests, late-bid rejections, closing-job delay, and the time between auction closure and order creation.
A correlation identifier should follow a bid from the API Gateway through validation, database storage, event publication, real-time delivery, and any resulting order.
Clock accuracy must also be monitored. Because closing decisions depend on server time, generator and bidding nodes should use reliable time synchronisation and alert when their clocks drift beyond an acceptable threshold.
Business monitoring can detect failures that infrastructure metrics miss. A sudden drop in accepted bids or completed auctions may indicate a serious problem even when all servers appear healthy.
During the interview, begin by defining the auction rules and consistency requirements. Clarify whether the platform uses fixed closing times, auction extensions, or proxy bidding.
Present the clients and API Gateway before introducing the main services. Explain that the Auction Service owns listing information and lifecycle state, while the Bid Service provides the authoritative ordering of bids.
Walk through a bid request from beginning to end. The service checks the idempotency key, validates the auction and amount, serialises the bid against competing requests, commits the bid and updated auction state, and then publishes an event.
The deep dive should focus on the trade-off between correctness and availability. If the bidding system cannot safely determine the current auction state, it may need to reject or temporarily pause bids. Accepting conflicting bids would be worse than a short interruption.
Be precise about the consistency boundary. Bids within one auction have a deterministic order. Bids for different auctions can be processed independently. Search results and real-time displays may be eventually consistent, but the direct bidding response and stored auction state are authoritative.
Finish by connecting the solution to the original requirements. The architecture supports several clients, fast search and browsing, strongly consistent bidding, live updates, reliable closing, and asynchronous order creation.
The platform could add automatic proxy bidding, reserve prices, fixed-price purchases, and auctions containing multiple identical items.
Seller services could be extended with inventory tools, bulk listing imports, pricing recommendations, and performance dashboards. Buyer features could include personalised recommendations and alerts when watched auctions are close to ending.
The settlement process could support escrow, identity verification, shipping labels, delivery tracking, refunds, and dispute resolution.
For international growth, the platform would need multiple currencies, regional payment providers, local tax rules, translated listings, and region-specific compliance controls.
Machine-learning systems could improve fraud detection, ranking, recommendations, and image moderation. These systems should assist the platform without becoming part of the critical bid-acceptance path.
The bidding architecture could also adapt dynamically to hot auctions. Listings attracting unusual traffic could be moved to dedicated processing capacity before their final minutes.
These improvements should be added according to measured demand. The core bidding and closing rules should remain small, understandable, and strongly protected because they determine the outcome of every auction.
An online auction platform combines a read-heavy marketplace with a highly consistent bidding system.
Web applications, mobile applications, and seller tools access the platform through an API Gateway. Separate services manage listings, bidding, search, watchlists, real-time updates, orders, payments, and notifications.
Auction browsing can use caching, search indexes, and eventual consistency. Bid processing requires an authoritative state and a deterministic order for every bid within an auction.
Each accepted bid is stored immutably and atomically updates the current auction state. Idempotency keys make retries safe, while a transactional outbox ensures that committed bids produce reliable events.
The auction closes through an atomic, retryable state transition. Once closed, the winning bid triggers order creation, payment, and notifications.
The central trade-off is unavoidable: bids for different auctions can be processed in parallel, but bids for one auction must be ordered. A strong design acknowledges this constraint and scales the surrounding system without weakening the correctness of the auction itself.