Should a user's 200 live room memberships, each checked individually, be one member collection under one key or 200 keys?

middlemust knowfreq 58%

answer

count the round trips per read pattern
membership test never moves the collection
per-key bookkeeping times two hundred
a lifetime attaches to the entry
all-or-nothing loss versus partial loss

basics

~20 s

One member collection: the checks are membership tests the server answers without moving the collection, and the group is one unit of work. Choose separate keys only when a membership must expire on its own.

solid answer

~50 s

With 200 members checked one at a time, a single collection under one key wins on almost every axis: a membership test is one round trip that returns a yes or no without the collection crossing the network, the exact size is one read, and the whole set of memberships is one unit of work and one unit of loss. The 200-key layout pays per-key bookkeeping on every element, makes "list everything this user is in" a multi-key operation, and spreads one logical fact over 200 entries that can partly disappear. The one thing it buys is real: each key can carry its own lifetime, and members inside a collection cannot. So the decision rule is: many keys when elements must expire or be evicted independently, one collection when they live and die together — with the collection's size bounded by the writer, because nothing else bounds it.

go deeper

for a junior

Know the two layouts and that a membership test against a collection returns only a yes or no — the collection itself never crosses the network. Say that a bounded group read together belongs under one key.

for a middle

Argue both directions with the magnitude in hand: round trips per read pattern, per-element bookkeeping against a full key per element, and the fact that a deadline attaches to the entry rather than to a member.

for a senior

Show where the single collection stops paying — an unbounded member count turns the entry into one large unit of work — and name who enforces the bound, since nothing in the store does.

for a principal

Decide the platform rule: which multi-element layouts are sanctioned, what bound every collection must declare, and how teams are stopped from discovering the limit in production.

What the two layouts actually are

The same fact — which rooms is this user currently in — can be stored two ways.

One collection under one key. A single entry whose value is an unordered collection of distinct members, one per room. The store can test whether a member is present, report the exact size, add or remove one member, and return the whole collection.
Many top-level keys. Two hundred separate entries, each named for one user-and-room pair, each present or absent.

Both are defensible modelling choices, which is why an interviewer who asks this without numbers has asked an unanswerable question. With 200 members, checked one at a time, the comparison resolves cleanly.

The axes that decide it

axis	one collection, one key	one key per element
check one membership	one round trip, answered server-side	one round trip
list everything the user has	one read of one entry	a multi-key operation
exact count	one read	count the keys that exist
per-element cost	member plus modest bookkeeping	a full key name plus full per-entry bookkeeping
independent lifetimes	impossible — the entry is the unit	natural — one deadline per key
partial loss	all or nothing	some elements can vanish alone
unit of server work	one operation over the entry	one operation per element

Four of those rows deserve a sentence each.

The membership test never moves the collection. Asking "is this member present" returns a yes or a no. Two hundred members, two million members — the reply is the same size. This is the property that makes the single-collection layout scale with reads, and it is why fetching the whole collection into the caller to check one member is the classic waste.
Per-element overhead is real but asymmetric. Every top-level entry carries the bytes of its key name plus whatever bookkeeping the store keeps per entry, and that bookkeeping is typically far larger than the few bytes of a member inside a collection — some stores additionally hold small collections in a compact representation, which widens the gap further. The exact numbers are one store's and belong to the memory subject; the direction is universal in this class.
A lifetime attaches to the entry, not to a member. This is the single most important asymmetry, and it is a property of the shape rather than a missing feature. If every room membership must lapse on its own schedule, one collection cannot express that; 200 keys can, trivially. If they all end together — the user disconnects — the collection expresses it better, because one deletion ends all 200.
The collection is one unit of work and one unit of loss. Adding a member is one operation the server runs to completion. But the flip side is that the entry is atomic in its disappearance too: on eviction or on a restart, either all 200 memberships are there or none are. With 200 keys you can end up with a partially-populated truth, which is usually worse to reason about, not better.

The decision rule

Use many top-level keys when at least one of these holds:

an element must carry its own deadline or be evicted on its own;
elements are written by parties that must not be able to see or affect each other's elements;
the collection has no natural bound and would otherwise grow without limit.

Use one collection under one key when:

the elements live and die as a group;
the dominant read is a membership test, an exact size, or the whole collection;
the member count is bounded and known, and a writer enforces the bound.

Where the single collection stops paying

The bound is the whole argument. Two hundred members is not the interesting case; two million under one key is. At that size the entry becomes one large unit — the whole-collection read is a single enormous reply, and the entry is a single piece of work the server must get through while other callers wait. Diagnosing that, and sizing a single entry, belong to the keyspace and access subjects; what belongs here is knowing that the layout choice is what created the situation, and that the repair is either a bound enforced on write or a split into several collections.

And because this is a volatile tier, both layouts share one premise: the memberships can vanish. The design has to say what the service does when a user's collection is simply not there — usually rebuild it from the live connections themselves, which is exactly why holding it here is acceptable at all.

## What the two layouts actually are The same fact — *which rooms is this user currently in* — can be stored two ways. - **One collection under one key.** A single entry whose value is an unordered collection of distinct members, one per room. The store can test whether a member is present, report the exact size, add or remove one member, and return the whole collection. - **Many top-level keys.** Two hundred separate entries, each named for one user-and-room pair, each present or absent. Both are defensible modelling choices, which is why an interviewer who asks this without numbers has asked an unanswerable question. With **200 members, checked one at a time**, the comparison resolves cleanly. ## The axes that decide it | axis | one collection, one key | one key per element | |---|---|---| | check one membership | one round trip, answered server-side | one round trip | | list everything the user has | one read of one entry | a multi-key operation | | exact count | one read | count the keys that exist | | per-element cost | member plus modest bookkeeping | a full key name plus full per-entry bookkeeping | | independent lifetimes | impossible — the entry is the unit | natural — one deadline per key | | partial loss | all or nothing | some elements can vanish alone | | unit of server work | one operation over the entry | one operation per element | Four of those rows deserve a sentence each. 1. **The membership test never moves the collection.** Asking "is this member present" returns a yes or a no. Two hundred members, two million members — the reply is the same size. This is the property that makes the single-collection layout scale with reads, and it is why fetching the whole collection into the caller to check one member is the classic waste. 2. **Per-element overhead is real but asymmetric.** Every top-level entry carries the bytes of its key name plus whatever bookkeeping the store keeps per entry, and that bookkeeping is typically far larger than the few bytes of a member inside a collection — some stores additionally hold small collections in a compact representation, which widens the gap further. The exact numbers are one store's and belong to the memory subject; the direction is universal in this class. 3. **A lifetime attaches to the entry, not to a member.** This is the single most important asymmetry, and it is a property of the shape rather than a missing feature. If every room membership must lapse on its own schedule, one collection cannot express that; 200 keys can, trivially. If they all end together — the user disconnects — the collection expresses it better, because one deletion ends all 200. 4. **The collection is one unit of work and one unit of loss.** Adding a member is one operation the server runs to completion. But the flip side is that the entry is atomic in its disappearance too: on eviction or on a restart, either all 200 memberships are there or none are. With 200 keys you can end up with a partially-populated truth, which is usually worse to reason about, not better. ## The decision rule Use **many top-level keys** when at least one of these holds: - an element must carry its own deadline or be evicted on its own; - elements are written by parties that must not be able to see or affect each other's elements; - the collection has no natural bound and would otherwise grow without limit. Use **one collection under one key** when: - the elements live and die as a group; - the dominant read is a membership test, an exact size, or the whole collection; - the member count is bounded and known, and a writer enforces the bound. ## Where the single collection stops paying The bound is the whole argument. Two hundred members is not the interesting case; two million under one key is. At that size the entry becomes one large unit — the whole-collection read is a single enormous reply, and the entry is a single piece of work the server must get through while other callers wait. Diagnosing that, and sizing a single entry, belong to the keyspace and access subjects; what belongs here is knowing that the layout choice is what created the situation, and that the repair is either a bound enforced on write or a split into several collections. And because this is a volatile tier, both layouts share one premise: the memberships can vanish. The design has to say what the service does when a user's collection is simply not there — usually rebuild it from the live connections themselves, which is exactly why holding it here is acceptable at all.

What single requirement would flip your answer to 200 separate keys?
That an individual membership must expire on its own — for example each one lapsing a fixed interval after the user last spoke in that room. A lifetime attaches to the entry, so members inside one collection cannot carry independent deadlines. Nothing else in this scenario is strong enough to overturn the single collection.
The product now wants the count of rooms per user on every request. Does that change the layout?
It strengthens the single collection. Its exact size is one read of one entry, independent of how many members it holds. With 200 keys the count means enumerating or maintaining a separate number alongside, which introduces a second thing to keep consistent with the first.
At what point would you split one collection into several?
When the member count stops being bounded by anything the writer controls, or when the whole-collection read becomes a reply large enough to matter. The split is usually by a natural partition of the members. How the split keys are named, and where the resulting entries land in a partitioned deployment, are the keyspace and distribution subjects.

saying these in an interview costs you the question

Fetches the whole collection into the caller to test one member
Thinks members inside one collection can each carry their own lifetime
Says many keys always cost less memory than one collection
Ignores the member count entirely and answers on style
Assumes one collection scales forever because reads are cheap
Treats partial loss across many keys as safer than all-or-nothing

Should a user's 200 live room memberships, each checked individually, be one member collection under one key or 200 keys?

§ answer

basics

solid answer

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What the two layouts actually are

The axes that decide it

The decision rule

Where the single collection stops paying

▾common follow-ups3 questions

▾red flags6 flags

What the two layouts actually are

The axes that decide it

The decision rule

Where the single collection stops paying

answer

go deeper