When everything happens at once
Events are not evenly distributed. Capacity that is comfortable on an average Tuesday is the wrong number for the ten minutes that pay for the year.
Averages are a poor way to size a real-time network, and the reason is not that the average is inaccurate. It is that the average describes the minutes nobody is paying for. Real-world events arrive in correlated bursts: a grid failure produces regulator notices, wire coverage, market prints, and industrial disclosures within the same few minutes, across several regions, all of it about the same underlying thing. The quiet hours are the product working; the burst is the product being used, and it is where a delivery guarantee stops being a paragraph.
Queueing theory makes the shape of this precise, and the arithmetic is worth carrying around. In the simplest model, average wait scales with 1/(1 - u) where u is utilization: at 50% a queue is barely a queue, at 80% waits are five times the service time, and at 95% they are twenty. The curve is not linear and there is no warning on the way up, which is why a system that looked comfortable at 70% on Tuesday is not comfortable at 95% for the ten minutes that matter. Headroom is not waste. Headroom is the entire mechanism by which a burst stays fast, and tail latency is where its absence shows up first.
Bursts are also the moment every other design decision gets tested at once. Connections that were held open have to stay open. Models that evaluate in flight have to keep their millisecond budget while the arrival rate multiplies. Deduplication gets harder precisely when it matters most, because a single event arriving through nine independent sources within ninety seconds is exactly the case where collapsing them correctly is the difference between one record and nine.
Then there is the question every real-time system eventually has to answer honestly: what happens when the arrival rate exceeds what the network can carry. The comfortable answer is that it never does, and it is not credible. The real answer is a stated policy, which is what backpressure is - buffer to a bound, then slow the producer, then shed defined work in a defined order. A system without one still does all three; it just does them arbitrarily, and discovers the order afterwards.
Evaluating urgency in flight is what makes the last of those defensible. If every record is judged before it queues, then a burst degrades by delaying the least urgent traffic rather than by dropping whatever happened to be at the head of the queue. That is a different guarantee from best effort, and it is one of the more useful consequences of doing the expensive work in the path rather than in a downstream job - a decision we made for latency reasons and have been repaid for under load.
Buffering deserves a caveat, because it looks like the safe choice and often is not. Holding a record for thirty seconds to avoid dropping it produces a delivery whose value may have expired in transit, and a queue that grows without bound converts a capacity problem into a memory failure some minutes later. For real-time data specifically, a late record and a lost one are closer in value than the architecture diagram suggests. What the client needs is not a promise that nothing is ever delayed, but a delivery guarantee precise enough to build against, and enough evidence on each record to tell which case they are holding.
The counterintuitive commercial conclusion is that most of what a real-time network costs is capacity that is idle most of the time. That is not inefficiency to be optimized away; it is the specific thing being purchased. A provider running close to capacity on an average day has quietly decided that its clients will be slowest during the events that make the difference, and the cost shows up in tail latency rather than in a headline number, and that decision does not appear anywhere in a datasheet.
So the useful diligence question is not what throughput a vendor sustains. It is what happens at four times that rate for ten minutes: what is delayed, what is shed, in what order, and how you would know from the provenance on the records you receive. A vendor that has never had to answer has never been in the burst.