FYI Current peaks for RTB are about 2.5m qps world-wide today. Some exchanges are seeing as many as 100B impressions per day with mobile and display impressions combined.
RTB is an amazing challenge and way too much fun for those inclined to bang their heads against all sorts of problems you never run across in the "regular" world.
I've done some work on these systems, one of my favorite challenges is writing tools that segment impressions in real time, you have only 10ms to respond because you're augmenting the bid before others can bid. A RTB bidder typically has about 100ms to respond. When you're shooting for 10ms at 2.5m qps peaks you have to think about everything from kernel versions, network settings, pinning to processors, avoiding GC, logging to disk is too slow etc.
As someone close to the RTB world observing from the outside, what amazes me is not the throughput or latency numbers but that it all happens on technology stacks that seem inappropriate for the problem. Everything from broadcast messages over TCP/IP or request/reply semantics for messages with no useful replies, to having to scale connections even though the number of participants is fixed. Its a whole world built on http that doesn't seem like it should be. That you can scale qps in that world while maintaining a semblance of response time is really something.
As a complete tangent, as someone who has worked in environments that had at least an order of magnitude tighter latency requirements than the RTB world, and who sees this misconception a lot, logging to disk on a modern OS is not "too slow". There may be very valid reasons not to log to disk, most obviously operational concerns, but latency/throughput aren't one of them.
RTB is an amazing challenge and way too much fun for those inclined to bang their heads against all sorts of problems you never run across in the "regular" world.
I've done some work on these systems, one of my favorite challenges is writing tools that segment impressions in real time, you have only 10ms to respond because you're augmenting the bid before others can bid. A RTB bidder typically has about 100ms to respond. When you're shooting for 10ms at 2.5m qps peaks you have to think about everything from kernel versions, network settings, pinning to processors, avoiding GC, logging to disk is too slow etc.