Twitter Snowflake IDs: Engineering Unique, Chronological Tweet Identifiers at Scale

Concrete problem: why tweet IDs need to be unique and ordered

Every tweet must have a globally unique identifier so that two users cannot receive the same ID, and the identifier should reflect creation time to enable efficient range queries and pagination.

Thesis: Snowflake IDs provide a compact 64‑bit solution that guarantees uniqueness and near‑chronological ordering

The design packs a 42‑bit timestamp, a 10‑bit worker identifier, and a 12‑bit sequence number into a single 64‑bit integer, giving Twitter the ability to store tweets in time‑ordered shards without expensive sorting.

How the 64‑bit layout works

The 64‑bit ID is divided as follows (most‑significant bits first):

• 42 bits – milliseconds since the Unix epoch (2026‑11‑12 04:31:38 UTC ≈ 1731477938000 ms)
• 10 bits – worker ID, identifying the server that generated the ID (Twitter runs many workers, each with a unique ID)
• 12 bits – sequence number, incrementing within a millisecond for the same worker

Because the timestamp dominates the value, IDs are roughly sorted by creation time, which lets Twitter read a range of tweets directly from a sharded database.

Worked example

Assume a tweet is created at 2026‑11‑12 04:31:38 UTC. The timestamp in milliseconds is 1731477938000. Using worker ID = 1 and sequence = 12345, the ID calculation yields:

0x5F9E7F5A00001E39

Breaking the hexadecimal value:

1. High 42 bits (0x5F9E7F5A0000) encode the timestamp 1731477938000.
2. Next 10 bits (0x000) represent worker = 1.
3. Lowest 12 bits (0x1E39) hold the sequence = 12345.

Inspecting the numeric ID confirms it follows the expected layout.

Trade‑off and limitation

The main engineering trade‑off is clock synchronization. If a worker’s clock drifts backward, the timestamp portion may decrease, causing the ID to become out‑of‑order or duplicate an earlier ID. Twitter mitigates this with a “tweeter‑clock” that only advances, but large data‑center skew can still break strict monotonicity.

Another limitation is the fixed 10‑bit worker space (1,024 distinct workers). Adding new servers requires coordination to avoid ID collisions, which adds operational overhead.

Actionable closing: verifying and using Snowflake IDs

To confirm that an ID conforms to the Snowflake format:

1. Obtain read permission on the Twitter API (or use a public endpoint that returns tweet objects).
2. Create a test tweet or retrieve a recent one via the API.
3. Extract the numeric “id” field and convert it to binary or hexadecimal.
4. Check that the high 42 bits correspond to the tweet’s creation timestamp (you can compute the expected timestamp from the UTC time).
5. Verify that the worker bits are within the 0‑1023 range and that the sequence number is less than 4096.

If any check fails, the ID may not be a valid Snowflake ID, indicating a potential issue with the service or with your integration.