Pattern · seen in 1 breakdown across 1 company
ID-Encoded Placement
Definition
Embed an object's storage location directly in its identifier — shard bits, type bits, local row bits packed into one integer — so that finding any object is arithmetic every client can perform, with no lookup service, directory tier, or hash ring on the read path. Identifier generation collapses into the same stroke: insert into the chosen shard, take the auto-incremented local ID, and the composed integer is a universally unique ID whose top bits are its address.
The scheme's power and its constraint are the same fact: because every stored reference contains the address, the address can never change — data is pinned to its shard for life, and rebalancing happens by moving whole shards between machines, never objects between shards. Boundary against hash-based placement (consistent hashing, mod-sharding): there the key is hashed to find a location, so placement can be recomputed when topology changes, at the cost of a hash function standing between every lookup and its data; ID-encoded placement removes the function and freezes the answer.
When it applies
Tradeoffs
The same move, 1 ways
Every row is a production system that bet on this pattern — the note says how, in that system's own terms.
Problems this pattern answers
The walls where its breakdowns live — each opens the cross-company comparison.