EASYwalkthrough
K-Sortability: What Time-Ordered IDs Buy
An ID could just be unique. Snowflake IDs are also k-sortable: sorted numerically, they come out approximately in creation order (exact within a worker, within-a-millisecond across workers is unordered: that is the "k").
And a subtle debugging gift: the timestamp is extractable: shift right 22 bits, add the epoch, and any ID tells you when it was created: support engineers date-attribute incidents from the ID alone. The limits keep you honest.
“This one property quietly powers half the product surface. Database write locality: inserts append to the right edge of the primary-key B-tree, keeping the hot page in cache and avoiding the random-insert page-split storm from the UUID discussion. Cursor pagination: "give me tweets after ID 17045...": the ID itself is the cursor; no OFFSET scans, no separate created_at index, stable pagination under concurrent writes. Cross-shard merging: fan out a timeline query to 8 shards, merge-sort the results by ID, and you have time order without timestamps: this is literally how sharded feeds assemble. Range-partitioned archival: old data is exactly the low-ID range; dropping a month of data is dropping an ID range, not a full-table scan.”
Ordering is per-worker exact but cross-worker only to the millisecond, so k-sortable is NOT a logical clock: do not use ID order to reason about causality between services (that is what vector clocks were for in the KV topic). And clock skew between workers bounds the k: monitoring worker skew is monitoring your ordering guarantee.
What if the interviewer asks: do we even need ordering: why not random 64-bit? Then you give back locality, cursors, shard merges, and archival, and you re-buy a created_at column plus its index on every table: ordering is the cheapest feature 41 bits ever bought.
Related concepts