Picture a room full of buyers at a traditional auction house, each holding a paddle, all watching the same auctioneer, all hearing every new bid announced at the exact same instant, in the exact same order. Nobody ever wonders “wait, did my bid actually count, and did it come before or after that other buyer’s bid?” — the room itself, and the auctioneer’s voice, make the order unambiguous to everyone at once.

Now take that same experience and scatter the buyers across a hundred different cities, each looking at their own laptop screen, submitting bids over an unreliable public internet connection, sometimes within milliseconds of each other. A real-time B2B bidding system is the software equivalent of that auctioneer’s room — a platform that lets many geographically distributed buyers compete for the same limited pool of supplier inventory through a live auction, while guaranteeing every single participant sees a fair, consistent, correctly-ordered view of who is currently winning, and the platform itself never allows more than one buyer to believe they’ve won the exact same lot.

1.1 Why B2B bidding is a different problem from consumer auctions

Consumer auction sites are a familiar mental starting point, but B2B real-time bidding for supplier inventory has its own distinct pressures that shape this architecture.

1.2 A short history of the problem

By the end of this tutorial, you will understand how to design a real-time bidding pipeline that combines the strict, fair ordering guarantees of a financial matching engine with the live, low-latency broadcast experience buyers expect from a modern web application.

1.3 Why this problem sits at the intersection of several disciplines

Building this well pulls together at least four distinct engineering disciplines, and a strong system designer needs to move comfortably between all of them.

Keeping this framing in mind helps you answer follow-up interview questions gracefully, since interviewers often probe from whichever of these four angles matches their own background — moving comfortably between “how do you guarantee ordering under concurrency” and “why does anti-sniping exist at all” and “how would you defend this outcome to an auditor” is exactly the kind of well-rounded judgment senior system design interviews are designed to surface.

Let’s ground this in the specific mechanics of the failure modes this system must prevent.

2.1 Why this is a genuinely hard system design problem

2.2 Why “just use a database row and a lock” doesn’t scale as an answer

It is tempting to imagine solving this with a single database row holding “current highest bid,” updated inside a transaction with a lock preventing concurrent writes. This works correctly for a single auction lot at low volume, but it does not answer several questions this tutorial needs to answer completely: how do you broadcast the new state to hundreds of live bidders the instant it changes, how do you extend the auction fairly if a bid arrives in the final seconds, how do you scale to thousands of simultaneous auction lots each with their own contention, and how do you produce a fully auditable history of every bid, accepted or rejected, and why. A single locked database row is a reasonable starting point for the correctness core of the problem, but the full system needs quite a bit more built around it.

2.3 The three stakeholders whose needs must all be balanced

2.4 Why fairness, not raw speed, is the true north star

It’s tempting to frame this purely as a low-latency engineering challenge, but speed alone is not the goal — a system that broadcasts updates in ten milliseconds but occasionally processes two nearly-simultaneous bids in the wrong order is worse than one that takes fifty milliseconds but is always provably correct. The entire architecture in this tutorial is built around getting the ordering guarantee unquestionably right first, and only then optimizing aggressively for speed within that constraint, rather than the reverse.

Before drawing the architecture, let’s build a shared vocabulary for every technique this system relies on.

3.1 Single-writer, per-auction sequencing

What: A design where every bid for a specific auction lot is processed by exactly one logical, ordered stream — often achieved by partitioning bids by auction lot identifier and ensuring only one consumer processes a given partition at a time.

Why: This is the single most important idea in the entire system. By guaranteeing that all bids for the same lot pass through one strictly ordered pipeline, the question “which bid came first” has one unambiguous, provable answer, even though bids for different lots are processed fully in parallel across the platform.

3.2 WebSockets and real-time fan-out

What: A persistent, bidirectional connection between a buyer’s browser and the server, allowing the server to push new bid updates instantly, without the client needing to ask.

Why: Polling for updates every few seconds is both slower than buyers expect in a competitive bidding context and wasteful at scale; a persistent connection lets the platform push the new highest bid the instant it is accepted.

Practical example: The moment the Auction Engine accepts a new highest bid, a broadcast service pushes that update to every WebSocket connection currently subscribed to that specific auction lot, typically within a couple hundred milliseconds.

3.3 Optimistic concurrency control

What: A concurrency strategy where a write includes the version of the data it expected to be modifying, and is rejected if that version has since changed, rather than acquiring a lock upfront and holding it for the duration of the operation.

Why: At high bid volume, holding a pessimistic lock on an auction lot’s state for the full duration of every bid’s validation would create a serialization bottleneck; optimistic concurrency lets validation happen without blocking, only rejecting and prompting a retry in the rare case of a genuine conflict.

3.4 Anti-sniping (auction extension)

What: A rule that automatically extends an auction’s closing time by a short window whenever a new qualifying bid is placed very close to the scheduled end, preventing a bidder from winning simply by waiting until the last possible instant.

Why: Without this, the fairest possible strategy for any sufficiently sophisticated bidder is to submit their true bid in the final second, denying every other participant any chance to respond — auction extension restores genuine competition right up to the true close.

Beginner example: If a new highest bid arrives with 10 seconds left on the clock, the auction automatically extends by, say, 60 more seconds, giving other bidders a fair chance to respond, and this can repeat as long as new qualifying bids keep arriving within the extension window.

3.5 Proxy bidding

What: A bidder specifies the maximum price they are willing to pay once, and the system automatically places incremental bids on their behalf, only as high as needed to remain the current leading bid, up to their specified maximum.

Why: This removes the need for a buyer to manually watch the auction and respond in real time to every competing bid, while still preserving genuine price competition, since the system only reveals as much of a buyer’s true maximum as competition actually requires.

3.6 Event sourcing

What: Storing every meaningful change as an immutable, ordered event (bid submitted, bid accepted, bid rejected, auction extended, auction closed) rather than only storing the current state, so the full history can always be reconstructed and replayed.

Why: Given the legal and financial stakes of an auction’s outcome, being able to reconstruct exactly what happened, in what order, and why any given bid was accepted or rejected, is not optional — it is a core requirement, and event sourcing provides this naturally as a byproduct of how state changes are stored in the first place.

3.7 Backpressure on the bid ingestion path

What: A signal that flows backward from the Auction Engine to the Bid Validation Service and API Gateway, indicating that bids for a specific lot are arriving faster than the single-writer pipeline can process them, so upstream components should slow acceptance rather than pile up an unbounded backlog.

Why: Because a single lot’s ordering guarantee fundamentally requires serialized processing, an extremely hot lot could otherwise accumulate an ever-growing queue of unprocessed bids, each one becoming progressively more stale by the time it’s finally evaluated; backpressure lets the system respond honestly, for example by briefly rejecting or delaying acceptance, rather than silently degrading fairness for bids stuck deep in a growing backlog.

3.8 Total ordering versus causal ordering

What: A total order arranges every event in one single, unambiguous sequence. A causal order only guarantees that events which genuinely depend on each other appear in the correct relative sequence, while independent events may be interleaved in any order.

Why: This system deliberately requires total ordering within a single auction lot — there is no meaningful concept of two bids on the same lot being “independent” of each other, since accepting one directly affects whether the next is even valid. Across different lots, however, only causal independence is needed, which is exactly why the partitioning-by-lot design is sufficient and appropriately not over-engineered into a single, platform-wide total order that would needlessly bottleneck the entire system.

Let’s assemble every concept above into one coherent picture. Every box below is a distinct, independently deployable component, labeled explicitly.

Every box above maps to a real, independently deployable component. Let’s walk through each one.

4.1 Component breakdown

Let’s zoom into the two mechanisms that make this system trustworthy: the Auction Engine’s per-bid decision logic, and the anti-sniping extension rule.

5.1 Auction Engine bid processing

Each bid arrives at the Auction Engine having already passed basic validation, and the engine now must apply the auction’s actual competitive rules — is this bid high enough to beat the current leader by at least the minimum increment, and if proxy bidding is enabled, how does it interact with any existing proxy maximums.

public class AuctionEngine {

    private final AuctionStateCache stateCache;
    private final EventStorePublisher eventPublisher;

    // Called exactly once per bid, strictly in arrival order, for a
    // single auction lot partition. No concurrent invocation for the
    // same lot is ever possible by construction of the partitioned queue.
    public BidDecision processBid(BidRequest bid) {

        AuctionLotState state = stateCache.get(bid.getLotId());

        if (state.isClosed()) {
            return BidDecision.rejected(bid, "Auction already closed");
        }

        BigDecimal requiredMinimum = state.getCurrentLeadingPrice()
                .add(state.getMinimumIncrement());

        if (bid.getAmount().compareTo(requiredMinimum) < 0) {
            return BidDecision.rejected(bid, "Below minimum required increment");
        }

        // Apply proxy bidding: the new bid only needs to beat the previous
        // leader by the minimum increment, not necessarily match its own
        // full submitted amount, if that amount exceeds what's required.
        BigDecimal effectivePrice = ProxyBiddingResolver.resolve(state, bid);

        state.setCurrentLeadingPrice(effectivePrice);
        state.setCurrentLeader(bid.getBuyerId());

        boolean extended = AntiSnipingRule.applyIfNeeded(state, bid.getSubmittedAt());

        stateCache.save(state);
        eventPublisher.publishBidAccepted(bid, effectivePrice, extended);

        return BidDecision.accepted(bid, effectivePrice, extended);
    }
}

Notice the comment at the top of the method: this code is only ever safe because the surrounding infrastructure guarantees exactly one invocation of this method at a time per auction lot. The engine itself contains no explicit locking, because the partitioning scheme upstream has already eliminated the possibility of concurrent access to a single lot’s state — a deliberate design choice that keeps this correctness-critical code as simple and reviewable as possible.

5.2 Anti-sniping extension logic

public class AntiSnipingRule {

    private static final Duration TRIGGER_WINDOW = Duration.ofSeconds(30);
    private static final Duration EXTENSION_AMOUNT = Duration.ofSeconds(60);

    public static boolean applyIfNeeded(AuctionLotState state, Instant bidTime) {

        Duration timeRemaining = Duration.between(bidTime, state.getScheduledCloseTime());

        if (timeRemaining.compareTo(TRIGGER_WINDOW) <= 0) {
            state.setScheduledCloseTime(bidTime.plus(EXTENSION_AMOUNT));
            return true;
        }
        return false;
    }
}

Let’s trace two competing bids through the system as a sequence of messages, including a near-close bid that triggers an anti-sniping extension.

6.1 Auction lot lifecycle states

7.1 Key trade-off: strict single-writer ordering vs raw throughput per lot

7.2 Key trade-off: full proxy bidding vs simple manual bidding only

Supporting proxy bidding provides genuine convenience and can improve overall price discovery, since buyers reveal their true willingness to pay only as much as competition requires. However, it also adds meaningful logic complexity to the Auction Engine’s core decision path — precisely the piece of the system where simplicity and provable correctness matter most. Some B2B platforms deliberately launch with manual bidding only, and add proxy bidding later once the core ordering and broadcast pipeline has proven itself reliable under real production load.

8.1 Horizontal scaling across independent auction lots

Because each auction lot’s bid stream is an independent partition, the platform scales its total bidding capacity by adding more partitions and more consumer instances across the Auction Engine fleet, exactly the way a partitioned messaging system scales any partitioned workload — the correctness constraint (single writer) applies only within a lot, never across the whole platform.

8.2 Applying Little’s Law to WebSocket fan-out

Little’s Law states $L = lambda W$, where $L$ is the average number of items in the system, $lambda$ is the arrival rate, and $W$ is the average time an item spends in the system. If a popular auction lot has 500 simultaneously connected bidders, and a new bid update needs to be delivered and rendered within an average of 200 milliseconds ($W$), the Broadcast Service and WebSocket Gateway together need enough concurrent fan-out capacity to push $L = 500$ messages within that 200 millisecond window for every single accepted bid — directly informing how many WebSocket Gateway instances and how much broadcast throughput must be provisioned per actively-watched lot.

8.3 Read-heavy auction browsing versus write-heavy active bidding

The vast majority of platform traffic is buyers browsing upcoming and past auction lots, which is a classic read-heavy workload well served by caching and read replicas. Active bidding on a currently open lot is a comparatively tiny fraction of total traffic by volume, but carries far higher correctness stakes per request — exactly the kind of workload split that justifies routing these two traffic types through entirely different backend paths, each optimized for its own very different profile.

8.4 CAP theorem trade-offs in this system

The CAP theorem states a distributed data store can only guarantee two of three properties during a network partition: consistency, availability, and partition tolerance. This architecture makes distinct, deliberate choices for different pieces of state.

This distinction matters enormously in an interview setting: the single place this system refuses any compromise on consistency is the ordering decision within a lot, while every other piece of state is free to trade some consistency for availability and simplicity, since the true cost of staleness there is genuinely low.

9.1 Multi-AZ deployment with partition failover

The Bid Ingestion Queue and Event Store are deployed across multiple availability zones, with each partition replicated so that the loss of a single broker does not lose any accepted bid. If the specific consumer instance processing a given lot’s partition fails, a replica or standby instance takes over, resuming from the last durably committed event, guaranteeing the ordering stream for that lot is never silently broken or duplicated.

9.2 Graceful degradation chain

9.3 Why the Auction Engine’s state must be durable, not just cached

Although the Auction State Cache provides fast reads for the next incoming bid’s validation, every accepted state change is also durably published to the Event Store before being considered final. If the cache were the only record of current state and it were lost, the platform would have no reliable way to reconstruct exactly who was leading a given lot and at what price — an unacceptable risk given the binding financial nature of the outcome.

9.4 Consensus and leader election for partition ownership

The Bid Ingestion Queue’s partitions, and therefore the responsibility for processing any given auction lot’s bids, are owned by exactly one consumer instance at a time, with ownership coordinated through a consensus protocol under the hood of the messaging platform. If the instance owning a hot lot’s partition fails mid-auction, the remaining instances run a leader election to promote a replacement, which resumes processing from the last durably committed event. This is precisely why every accepted bid must be durably published to the Event Store before being considered final — a mid-processing failure must never lose or duplicate a bid’s effect, regardless of which specific instance ultimately ends up owning that lot’s partition afterward.

9.5 Rehearsing the concurrent-bid race scenario directly

Beyond generic failure injection, teams building this specific system benefit enormously from a dedicated test that deliberately fires many near-simultaneous bids at the same hot lot from many parallel clients, verifying the single-writer guarantee holds under genuine concurrent pressure and produces a fully deterministic, correct, and reproducible outcome every single time it’s run.

10.1 Preventing shill bidding and collusion

Shill bidding — a seller or their associate placing fake bids purely to drive up the price without any genuine intent to win — is a serious integrity risk in any auction platform. The Fraud Detection Service analyzes bidding patterns for signals such as accounts closely tied to the supplier bidding on that supplier’s own lots, or a cluster of accounts sharing suspicious identifying characteristics that repeatedly bid against each other in a coordinated pattern.

10.2 Protecting proxy bid maximums

A buyer’s true maximum proxy bid amount is highly sensitive competitive information — if another buyer or the platform itself leaked it, that buyer would lose any negotiating advantage. Proxy maximums are stored encrypted and are never exposed through any API response or broadcast event; only the effective current bid needed to maintain the lead is ever revealed publicly, exactly mirroring how proxy bidding works in a traditional, in-person auction house.

11.1 Key metrics to track

11.2 Distributed tracing across the bid pipeline

Every bid carries a correlation identifier from the moment it is submitted through validation, ingestion, the Auction Engine’s decision, event publication, and broadcast, allowing an engineer to reconstruct the exact millisecond-by-millisecond path of any specific bid, which is invaluable both for performance debugging and for investigating a buyer’s dispute about why their bid was rejected or arrived too late.

12.1 Independent scaling of stateless and stateful tiers

The Bid Validation Service, API Gateway, and WebSocket Gateway are stateless and scale horizontally through standard auto-scaling based on connection count and request volume. The Auction Engine, by contrast, scales by adjusting the number of partitions and consumer instances, a fundamentally different scaling dimension tied to the number of simultaneously active auction lots rather than raw request volume alone.

12.2 Canary rollout for Auction Engine logic changes

Given how directly the Auction Engine’s logic determines binding financial outcomes, any change to its bidding rules or proxy bidding resolution logic is rolled out with extreme caution — first validated extensively in a staging environment replaying historical real auction event logs, then piloted on a small number of genuinely low-stakes auction lots, before being trusted with high-value production auctions.

12.3 Blue-green deployment for the WebSocket Gateway

Because WebSocket connections are persistent and stateful at the connection level, deploying a new version typically uses a blue-green strategy where new connections are routed to the new version while existing connections on the old version are allowed to gracefully drain and reconnect, avoiding an abrupt mass disconnection of every actively bidding buyer mid-auction.

13.1 Why the Auction Database favors strong consistency for lot state

The durable record of every accepted bid and every auction lifecycle event demands strong consistency — two conflicting views of who currently holds the winning bid is not a tolerable inconsistency window given the binding financial nature of the eventual outcome, so writes to the Event Store and Auction Database are never allowed to be eventually consistent with respect to a single lot’s ordering.

13.2 Caching for auction browsing versus no caching for active bid state

Upcoming and past auction listings, supplier profiles, and category browsing are aggressively cached, since staleness here carries essentially no correctness risk. The current leading bid and time remaining for an actively open lot, by contrast, is never served from a generic cache layer to a decision-making code path — only the Auction Engine’s own tightly-controlled state cache, which it exclusively owns and updates, is trusted for this purpose.

13.3 Load balancing strategy for WebSocket connections

Layer 7 load balancing with support for long-lived connections routes new WebSocket upgrade requests using a strategy that accounts for existing connection counts per instance, avoiding a scenario where new connections pile disproportionately onto instances that already hold many long-lived, resource-consuming connections from earlier in the day.

14.1 Sample bid submission API

@RestController
@RequestMapping("/api/v1/auctions/{lotId}/bids")
public class BidController {

    private final BidValidationService validationService;
    private final BidQueuePublisher queuePublisher;

    @PostMapping
    public ResponseEntity<BidResponse> submitBid(
            @PathVariable String lotId,
            @RequestHeader("Idempotency-Key") String idempotencyKey,
            @RequestBody BidRequest request) {

        ValidationResult validation = validationService.validate(lotId, request);
        if (!validation.isValid()) {
            return ResponseEntity.badRequest().body(BidResponse.rejected(validation.getReason()));
        }

        // Enqueued to the partition for this specific lot; the Auction
        // Engine will process it strictly in arrival order relative to
        // every other bid for the same lot.
        queuePublisher.publish(lotId, request, idempotencyKey);

        return ResponseEntity.accepted().body(BidResponse.submitted(idempotencyKey));
    }
}

14.2 Why the public bid API is asynchronous, not synchronous end to end

The endpoint returns as soon as the bid is durably enqueued, not after the Auction Engine has actually rendered its accept-or-reject decision. The buyer’s client instead learns the outcome through its WebSocket subscription, exactly the same channel every other watching buyer uses — ensuring the bidder who submitted the bid and every other observer of the auction learn the outcome through the same consistent, real-time path, rather than the submitter potentially learning it slightly differently or slightly earlier through a separate synchronous response.

14.3 Why microservices, not a monolith, for this domain

Bid validation, the Auction Engine, WebSocket connection management, and fraud detection each have distinct scaling dimensions and risk profiles — the Auction Engine’s correctness-critical, partition-bound logic benefits from being kept as small and simple as possible, while the WebSocket Gateway’s scaling is driven by total concurrent connections, an entirely different concern. Splitting these into independent services lets each be developed, tested, and deployed according to its own appropriate cadence and caution level.

15.1 Anti-patterns to avoid

17.1 A common pattern across all of these examples

Every system described above, despite operating at wildly different speeds and serving very different markets, converges on the same underlying shape: a single, authoritative, strictly-ordered decision-making component per independently-competing unit, paired with a fast, decoupled broadcast mechanism to keep every interested party informed. This convergence reflects a genuine, unavoidable property of any competitive real-time bidding problem — you cannot have a fair, unambiguous winner without an unambiguous, agreed-upon order of events, and you cannot have a satisfying real-time experience without decoupling that correctness-critical decision from the comparatively less time-critical work of telling everyone about it. Recognizing this pattern is itself a valuable piece of system design intuition: whenever a problem involves many competitors racing for a scarce, contested resource under a real-time deadline, this same shape of solution — strict single-writer ordering per contested resource, decoupled from a fast broadcast layer — tends to reappear, regardless of the specific industry or the specific technology stack chosen to implement it.

A real-time auction system earns buyers’ trust not by being fast, but by being unambiguously fair — and the fastest possible broadcast is worthless if the underlying ordering decision it’s broadcasting was never provably correct in the first place.Closing principle for this system design

If you take away only one idea from this entire tutorial, let it be this: every architectural decision described here — partitioning bids by auction lot to guarantee single-writer ordering, decoupling that correctness-critical decision from the broadcast mechanism that tells everyone about it, and recording every event immutably for later audit — traces back to the same foundational requirement stated at the very beginning. A real auction, whether in a physical room or across a distributed network, only works if every participant trusts that the order of events was genuinely fair and unambiguous. Once you hold that single requirement firmly in mind, the specific technical choices in this tutorial stop looking like an arbitrary collection of distributed systems techniques and start looking like the necessary, deliberate answer to a problem that is, underneath all the technology, fundamentally about trust.

It is also worth remembering that no amount of clever engineering substitutes for genuinely testing the exact scenario this fairness guarantee depends on. A single-writer ordering guarantee that has only ever been exercised by a unit test with two sequential calls has not really been tested at all; the teams that trust this kind of system in production are the ones who have deliberately, repeatedly, and successfully thrown genuine concurrent load at their busiest simulated auction lots, and watched the system produce the same correct, deterministic outcome every single time.