Snowflake IDs

TechniqueIdentifiers and OrderingSeniorStaffUpdated Nov 10, 2026

64-bit unique IDs: [timestamp][machine-id][sequence]. Time-ordered, distributed, no central coordinator.

When to Use Snowflake IDs

Need globally unique IDs that are also roughly sortable by creation time, across many shards/machines. Beats UUIDs for index locality (better B-tree fanout).

In Practice

Twitter coined Snowflake in 2010 for tweet IDs. Discord uses a variant for messages. Sonyflake (Sony) and Instagram's ID gen are spiritual descendants.

Sketch

Java

// 41 bits timestamp | 10 bits machine | 12 bits sequence
long id = ((now - EPOCH) << 22) | (machineId << 12) | (sequence++ & 0xFFF);

How Snowflake IDs Comes Up in Interviews

Scenario

You're designing IDs for a new social feed. They must be 64-bit, globally unique across hundreds of generators with no central coordinator, and roughly sortable by creation time. What pattern matches?

Snowflake packs [timestamp][machine-id][sequence] into 64 bits: decentralized, time-ordered, no coordinator. UUID v7 is similar but 128-bit; the 64-bit constraint pins this to Snowflake.

Snowflake's [41 bits timestamp | 10 bits machine ID | 12 bits sequence] layout fits in a signed 64-bit integer, which is critical for languages and storage systems that handle 64-bit ints natively but not 128-bit UUIDs. The time prefix gives natural k-sortability (later IDs sort after earlier ones), which means B-tree inserts land near the end of the index: hot pages, good cache behavior, instead of randomly scattering like UUID v4. Twitter open-sourced Snowflake in 2010; Discord uses a near-identical scheme for messages; Sony's Sonyflake and Instagram's ID gen are direct descendants. The clock-going-backwards problem (NTP correction, leap seconds) is the gotcha, production implementations all refuse to generate IDs if the clock moves backward.