EASYwalkthrough
Custom Epochs and the 69-Year Clock
Forty-one bits of milliseconds is ms: 69.7 years of ID space. From when?
So every Snowflake deployment picks a custom epoch: Twitter chose 2010-11-04; Discord chose 2015-01-01 (their first message); your system chooses its launch date: and the 69.7-year clock starts there. This looks like trivia until you enumerate what it touches. Interoperability: extracting a timestamp from an ID requires knowing the epoch: it is a contract, documented and versioned, because analytics pipelines, debuggers, and partner integrations all decode IDs.
“If you count from the Unix epoch (1970), you burned 50+ of those years before generating your first ID: the timestamp field would already be huge, and you would overflow in the 2030s.”
Change it and every decoder breaks silently. Sign-bit discipline: the top bit stays zero so IDs remain positive int64 everywhere; the day your timestamp needs bit 41, IDs flip sign in languages that treat them as signed: that IS your overflow event, in year ~69, not year 292. Migration planning: 69 years sounds like forever; the interview-grade observation is that the epoch is the ONE parameter you cannot rotate in place. Real escape hatches, in order of preference: spend fewer bits on sequence or workers to extend the clock (Sonyflake's 10ms ticks = 174 years), shard the ID space by a version prefix carried outside the 64 bits (an API-level id_version field), or accept a coordinated cutover to a new epoch with a guaranteed-higher base so ordering survives.
And the quiet operational rule: never generate IDs with a test epoch in production: mixed epochs interleave wrongly forever, and you cannot re-sort issued IDs. What if the interviewer asks: is 69 years actually enough?
For one product, almost certainly; the honest risk is not running out: it is merging systems (acquisitions, platform consolidation) whose epochs differ: which is why the decode contract matters more than the horizon.
Related concepts