Two members of a score-ordered set carry the same score - what decides their relative rank, and why not depend on it?
answer
- the score ran out of information
- stores differ on equal scores
- make the order total yourself
- pack the tie-break into the number
- mind the score's numeric precision
basics
~20 sThe supplied score alone does not decide it, and stores differ: some define a secondary ordering among equal scores, others document none. A design that needs a definite order must fold the tie-break into the score itself rather than rely on the store.
solid answer
~50 sThe ordering score is the only thing the caller gives the store, so equally scored members are, as far as the model goes, interchangeable. Some stores in this class settle ties by a defined secondary rule and some make no promise, which means a rank read at a tie may put either member first and the answer may differ between stores or between calls. It surfaces where it hurts: paging through positions can repeat or skip a member, and a cut at position N picks arbitrarily among the members sitting on the boundary. The repair is to make the order total in the number - combine the primary quantity with a tie-break such as an inverted time into one comparable score - and to check what numeric precision the store gives scores before packing two fields into one.
go deeper
Remember that the store only knows the number you gave it. Two members with the same number are not distinguished by the model, so nothing guarantees which of them a rank read puts first.
Explain where the ambiguity surfaces - a cut at position N, paging by position, anything derived from rank - and describe folding the tie-break into a single comparable score as the fix.
Add the practical traps: the numeric precision a composite score needs, the read patterns a composite changes, and why a second entry holding the tie-break is fragile on a tier that can lose either one.
Treat the tie-break as a product decision that has to be recorded, because it is encoded in the stored scores and any rebuild after the tier is lost must reproduce it or the ranking changes under users.
## A score is not automatically a total order The caller supplies one number per member and the store arranges members by it. When two members carry the same number, the supplied information runs out. What happens then is not part of the shape: - some stores define a **secondary ordering** among equal scores, derived from the member itself; - others make **no documented promise** at all; - and where a rule does exist, it is that store's rule, so a design built on it silently changes meaning if the store changes. The practical stance is to treat the relative order of equally scored members as **undefined** and to supply the tie-break yourself if the feature needs one. ## Where the ambiguity actually bites - **A cut at position N.** `The top ten` has to pick among the members sitting on the boundary at the same score. Whoever is cut off has a legitimate complaint, and the cut may differ between two reads. - **Paging by position.** Reading positions 0-49, then 50-99, assumes stable positions between calls. Ties make positions among equals arbitrary, and concurrent writes move members anyway, so a member can appear twice or not at all. Paging by score band rather than by position, with an explicit tie-break in the score, is the sturdier approach. - **Anything derived from rank.** A prize, a quota, an assignment or a display position built on `who is ahead` inherits the ambiguity, and the resulting bug report is about fairness rather than about the store. - **Time windows and due-time queues**, where scores are clock readings, tie far more often than a ranking of accumulated points does - especially when the clock is coarse. ## Making the order total 1. **Decide the tie-break rule first**, as a product question: earliest achiever wins, most recent activity wins, lowest identifier wins. If nobody can answer it, the ambiguity may genuinely be acceptable - and then say so explicitly rather than leaving it undiscovered. 2. **Encode it into one comparable number.** Put the primary quantity in the high-order part and the tie-break in the low-order part. For `highest points, earliest achiever first`, invert the time component so that an earlier moment produces a larger combined score. 3. **Check the precision you actually have.** The numeric type a store uses for scores varies, and where it is a floating-point type the low-order bits of a packed composite can be lost, which quietly reunites the members you just separated. Verify the usable range before packing, and prefer a coarser tie-break that fits over a precise one that does not. 4. **Verify the reads still answer.** A composite score changes what a range read by score means: a band that used to be `points between 100 and 200` now has to be expressed over the composite. If reading by the primary quantity matters, this is a real cost of the technique. ## The alternative, and its price The other way to break ties is to keep the tie-break somewhere else - a second collection, or a field on the member's own entry - and consult it after the ordered read. That keeps the score simple and readable, but it costs a second round trip on every read, and the two stores of truth can disagree after a partial failure on a tier where either entry can vanish independently. On a volatile tier that second source may simply not be there when you need it. Prefer the composite score unless the precision genuinely does not allow it. ## What varies between stores - **Whether ties are broken at all**, and by what rule, as described above. - **The numeric type of the score** and therefore the precision available for a composite. - **Whether a rank read is defined for a member sitting among equals** in any stable way across calls. This is a good example of the habit the whole subject rewards: the mechanism - members ordered by a caller-supplied number - is identical everywhere, and the edge of the mechanism is where the stores stop agreeing. Describe the mechanism confidently, and name the edge as varying rather than asserting the behaviour of the store you happen to know. ## And the tier is still volatile A tie-break policy is part of the data, since it lives inside the scores you wrote. If the entry is evicted or lost on a restart and rebuilt from a durable source, the rebuild has to reproduce the same composite scores, or the ranking will come back subtly different from the one users saw an hour earlier. That is worth writing down next to the rebuild path, because it is exactly the kind of detail a rebuild written six months later will miss.
- Why is paging by position over a live score-ordered set unreliable even without ties?Because positions are relative. Any write between two pages can move a member across the page boundary, so a member can be returned twice or skipped entirely. Ties make it worse by leaving the order among equals arbitrary. Paging by a score band, with a tie-break folded into the score, gives a cursor that does not shift under concurrent writes.
- What goes wrong when the tie-break is kept in a second entry instead of in the score?Two costs. Every ordered read needs a second read to resolve ties, doubling round trips on the hot path. And the two entries live independently on a volatile tier, so one can be evicted or lost while the other survives, leaving a ranking whose tie-break source has disappeared. A composite score keeps both facts in one place.
saying these in an interview costs you the question
- Assumes the earlier write always ranks first among equal scores
- Believes the store invents a small offset to keep scores unique
- Pages through ranks on a live collection and expects stability
- Packs a composite score without checking numeric precision
- Treats one store's tie behaviour as the model for all