oversubscription
A gym sells a thousand memberships even though it only has room for two hundred people at once, betting that they will never all show up together. An airline sells more tickets than seats for the same reason. This deliberate over-selling of a shared resource — counting on the fact that not everyone uses their full share at the same moment — is called oversubscription. It is a cost-saving gamble: you provide far less capacity than the worst case would demand, because the worst case is rare, and you save a lot of money in exchange for occasionally falling short.
In a datacenter the over-sold resource is network bandwidth up the tree. Consider a rack of 40 servers, each able to send 25 Gb/s — that is 1000 Gb/s of total downward capacity. If the top-of-rack switch has only 100 Gb/s of uplink to the rest of the building, then the rack is oversubscribed 10:1: ten times more bandwidth exists among the servers than exists to carry their traffic out. As long as the servers mostly talk within the rack or send modest cross-rack traffic, the uplink is fine. But if many of them try to blast data across the building at once, the uplink cannot carry it all and packets queue or drop. The oversubscription ratio (here 10:1) measures exactly how much you have under-provisioned.
Oversubscription is everywhere in WSC design because building a fully non-blocking network — enough core bandwidth for every server to send at full rate simultaneously — is extremely expensive, and real workloads almost never need it. So architects pick a ratio that balances cost against the risk of congestion, usually relying on the locality of traffic (most chatter stays inside a rack) to keep the over-sold upper layers from saturating. It is a quintessential warehouse-scale tradeoff: spend less, accept that the average case is fine and only the rare all-at-once case suffers.
Be honest about the failure mode. Oversubscription works until everyone shows up at once. A traffic pattern where all racks suddenly need to exchange a lot of data — a big shuffle phase, a backup storm, a cascading retry — can saturate the oversubscribed core and inflate latency for everybody, including unrelated jobs. So the savings are real but conditional; the ratio is a bet on traffic patterns, and bad placement or a bursty workload can make that bet lose.
Rack: 40 servers x 25 Gb/s = 1000 Gb/s downward, but only 100 Gb/s of uplink. Oversubscription ratio 10:1. Day to day, traffic stays local and 100 Gb/s is plenty. During a giant cross-rack shuffle, all servers want the uplink at once, it saturates, and latency spikes for everyone.
A 10:1 ratio saves money and works most of the time — until a traffic burst makes everyone want the scarce uplink at once.
Oversubscription is a bet that not all traffic peaks at once. It saves a lot of money but can collapse under all-to-all communication patterns like a big shuffle, inflating latency for unrelated jobs too.