When a load balancer hashes requests across 16 shards, what must hold before calling each shard's share exactly 1/16?
answer
- probability here is a counting statement
- favourable over total, nothing more
- equally likely, exclusive, exhaustive
- hash spreads keys, not request volume
- denominator moves during a resize
basics
~20 sDividing favourable outcomes by total outcomes is valid only when the outcomes are equally likely, mutually exclusive and exhaustive. A 1/16 share assumes the hash spreads the actual traffic uniformly, each request lands on exactly one shard, and the shard count is fixed.
solid answer
~40 sThe figure comes from counting, not from probability theory: the sample space is the 16 shards, one of them is favourable, so the answer is `1/16`. That division is only meaningful if the 16 outcomes are equally likely, if a request cannot land on two of them, and if there is no seventeenth outcome. In a routing layer the first assumption is the fragile one - a good hash spreads *distinct keys* evenly, while load follows *request volume*, so one dominant key hands its shard far more than a sixteenth of traffic. The denominator moves too: a resize changes the outcome count, and two shards co-resident on one host must be merged into a single outcome worth `2/16` when the question is about hosts.
go deeper
Recall the formula: probability equals favourable outcomes divided by total outcomes, and it only applies when the outcomes are equally likely. Be able to say that 16 equally likely shards give a one-in-sixteen chance for any one of them.
Explain the three conditions behind the division and show where routing breaks the first one: hashing spreads distinct keys, while load follows request volume, so a hot key skews a shard regardless of hash quality.
Demonstrate that you check the model against measurements before trusting it. Compare observed per-shard rates with the uniform prediction, and treat a persistent gap as information about the key distribution rather than a defect in the hash.
Frame the tradeoff: a uniform-outcome assumption is cheap and usually good enough, while explicit weighting or key-aware placement costs complexity. Decide which shards' skew would actually hurt, and spend the complexity only there.
## Probability as a counting statement When every outcome of a trial is equally likely, the probability of an event is a **count**: the number of outcomes in which the event happens, divided by the number of outcomes altogether. Hashing a request key to one of 16 shards looks like exactly that trial - sixteen outcomes, one of them is "the shard I asked about", so the answer is `1/16`. Notice that the division does no probabilistic work. It is arithmetic over a set you claim to have enumerated correctly, which means every mistake in this model is a mistake in the enumeration. The model carries three requirements, and an interviewer asking this question is usually checking whether you can name them: 1. **Equally likely.** Each of the 16 outcomes must carry the same weight. This is an assumption about the world, not something the arithmetic supplies. 2. **Mutually exclusive.** A single request must not be counted under two outcomes; otherwise the favourable counts overlap and the shares do not sum to one. 3. **Exhaustive.** The 16 outcomes must cover every possibility. If a request can be rejected, parked or routed to a spare, the denominator is wrong. ## What "equally likely" actually asserts Uniformity is a joint property of the hash function **and** the traffic it is fed. A hash with good avalanche behaviour scatters *distinct keys* across the output range evenly, and that is the property such functions are designed and tested for. It says nothing whatever about how many requests each distinct key attracts. If one key carries 40% of the traffic, the shard that key lands on carries at least 40% of the traffic, and it does so no matter how beautifully the hash mixes bits. The randomness decides *which* shard gets the hot key, not whether some shard gets it. This is the single most common failure of the model in a routing layer, and it is why capacity work distinguishes the two counts explicitly. | What you count as an outcome | The probability it yields | When it is the right model | |---|---|---| | One distinct key | Chance a *key* lands on a given shard | Sizing key-space spread, index cardinality | | One request | Chance a *request* lands on a given shard | Sizing load, queue depth, tail latency | | One shard-hour | Chance a given shard is the busy one | Comparing shards over a window | The uniform `1/16` answer is honest for the first row and merely hopeful for the second. ## Where the denominator moves The "total outcomes" side is not a constant of nature either. - **A resize.** The moment a seventeenth shard begins accepting traffic, the sample space has 17 members and the old denominator describes nothing. During the transition there may be two overlapping sample spaces at once, which is why routing changes are usually drained rather than reasoned about probabilistically. - **Co-residency.** Two shards pinned to one host are two outcomes for the routing question and **one** outcome for the host-capacity question. Merging them gives `2/16 = 1/8`, and forgetting to merge them understates that host's load by half. - **Uneven ownership.** When shards own unequal slices of the hash range - different numbers of virtual nodes, a range split that was never rebalanced - the outcomes are still mutually exclusive and exhaustive, but they are no longer equally likely, so favourable-over-total is simply the wrong formula. You must weight each shard by the fraction of the range it owns. ## A single request versus an observed share `1/16` is a statement about one request. It is not a promise that any finite window of traffic splits sixteen ways, and an interviewer will sometimes push on exactly that. Over a window of a thousand requests you should expect visible imbalance; the model predicts the per-request chance, and the observed share is a separate quantity that merely tends toward it as the window grows. ## What to say when asked - State the formula as a count, and immediately name the equally-likely assumption as the load-bearing one. - Separate distinct keys from request volume, and say that hashing controls the first, never the second. - Say what would make the denominator wrong: a resize in flight, a fallback route, outcomes that must be merged for the question actually being asked. - Offer the check an engineer can run: compare measured per-shard request rates against the uniform prediction, and treat a persistent gap as evidence about the key distribution rather than about the hash.
- Two of the 16 shards sit on one host - does 1/16 still describe what that host sees?No. The question has changed, so the sample space must change with it. For the host, the two shard outcomes merge into one favourable event, giving `2/16 = 1/8`. Outcomes may always be merged, because they are mutually exclusive; forgetting to merge them understates that host's expected load by half.
- Why does weighting keys by request volume change the answer at all?Because the equally-likely assumption applies to whatever you declared an outcome. Treating each distinct key as one outcome makes every key equal, which is false when one key is called far more often. Weight each key by its request rate instead, and a shard's expected share becomes the total weight that hashes to it - which a single dominant key can push far above a sixteenth.
saying these in an interview costs you the question
- Assumes any hash function is uniform on any key set
- Thinks an even key spread guarantees an even request load
- Keeps the 1/16 figure while shards are being added
- Never checks that the outcomes cover every route
- Confuses the long-run share with a per-request guarantee