System
Real-Time Ad Bidding.
End-to-end bid resolution at an ad exchange.
Eight message hops, four micro-dataservices, sub-2-millisecond bid resolution end-to-end, and zero data loss through deliberate failover.
Problem
A financial market in everything but name.
Real-time bidding for online ad impressions is a financial market in everything but name. Every page load triggers an auction; bidders must respond within tens of milliseconds; the system must process the bids reliably, sustain bursty traffic without degradation, and scale elastically across geography and campaign activity.
Prior RTB implementations met those targets only with substantial custom infrastructure work, including bespoke I/O, threading, messaging, and serialization. These were built because the standard abstractions (servlet containers, ORMs, generic serializers) introduced too much latency and memory pressure. The cost was paid in engineering time, garbage-collection pauses, and large hardware footprints just to reach baseline.
Architectural Constraint
Bid decisions are data-intensive, and the data lives across a network.
Bidding decisions are data-intensive, drawing on campaign rules, user profiles, and demand-side parameters. The data is large enough that fetching it across a network on the bid path is not workable inside a millisecond budget. Caching helps until durability becomes a requirement.
Java systems pay an additional tax in GC pauses driven by the serialization and deserialization at the boundaries. As with the other systems on this page, the bottleneck is not the database or the compute. It is the network between them.
Rumi solution
Four micro-dataservices, one binary message bus.
The full bidding system was built as four Rumi micro-dataservices, with SSP, Ad Exchange, DMP, and DSP each independently replicated for high availability and partitioned for horizontal scale. Inter-service communication runs over Rumi’s binary message bus.
The DMP holds hundreds of millions of user tracking records in memory. The DSP holds 1,000 active campaigns in memory. The Ad Exchange is co-located with the DSP, minimizing the most expensive step in the auction path. External clients see a standard HTTP/REST/JSON API.
Operational Outcomes
1.4 ms across eight hops, on three commodity servers.
- 3 serverscommodity hardware, dual 10-core 3 GHz, 96 GB RAM each
- 1.4 msend-to-end bid resolution across 8 message hops
- 24–62 µsper-hop latency (DSP campaign evaluation at 463 µs dominates)
- 1,000 / 100,000active campaigns and ad requests in the sustained test
- <1 secondprimary-to-backup failover; ~7% transient SLA breach
- Zerodata loss through deliberate primary termination