jonnifyelixir
F4 · Algorithms & Data Structures / F4.07 · identifiers

F4 · Persistent maps · module 7

Identifiers, Snowflake & branded ids

Every row in F4.04’s page registry, every user and session in the portal, needs a name. A database counter (1, 2, 3…) names them in one place, but the moment two machines mint ids at once it breaks. A Snowflake answers that: a 64-bit integer that carries its own millisecond timestamp, the worker that made it, and a per-millisecond sequence — sortable by time and unique without a central counter. A branded id wraps it for the outside world: a three-letter namespace and a base62 encoding, e.g. TSK0KHTOWnGLuC.

This is the id behind every other module’s keys: the registry of F4.04 keys %Page{} rows by one, the trie of F4.05/F4.06 hashes it, and F4.09 keys a branded CHAMP on it. The build stamp at the foot of every page in this course is one of these.

A Snowflake is 64 bits

64-bit integer, high bits first 0 1b timestamp ms since epoch 41 bits machine 0 10 bits seq 0 12 bits ↓ (ts << 22) | (machine << 12) | seq decimal id 274557032793636864 branded id = "TSK" <> base62(id) TSK 0KHTOWnGLuC 2026-01-27 15:11:37 UTC · worker 0 · sequence 0

TSK0KHTOWnGLuC · seq 0
Mint advances the sequence within the millisecond; on overflow the timestamp ticks.

The anatomy of a branded id

A branded id is two parts glued together: a three-letter namespace that names the kind of thing (TSK for a task, USR for a user) and an eleven-character base62 payload that is a 64-bit Snowflake. The namespace lets a service route an id without decoding it; the payload, once decoded, hands back a timestamp and more. Select a part to read.

What to read · select one

branded id (14 chars) TSK namespace 0KHTOWnGLuC base62(snowflake), 11 chars ↓ 64-bit Snowflake = 274557032793636864 timestamp (42b) node 10b seq 12b → 2026-01-27 15:11:37 UTC · node 0 · seq 0 TSK names the entity; the rest is a base62 Snowflake

      

role: the namespace names the entity

result: TSK · task

One string carries a type and a timestamped, coordination-free integer. A service can route on the first three characters and never decode the rest; a database can store the integer and sort by it.

Three deep dives

In order: why a counter and a random UUID both fall short and a Snowflake is the answer; how the 64 bits are laid out and read; and how the integer becomes the branded string the portal hands out.

F4.07.1
Choosing an identifier
From an auto-increment counter to a random UUID to a Snowflake: which properties each one keeps, and which it gives up.
F4.07.2
The Snowflake bigint
A 64-bit integer split into a 42-bit timestamp, a 10-bit worker, and a 12-bit sequence, read with shifts and masks.
F4.07.3
Branded ids
A namespace prefix and a base62 encoding turn the integer into a compact, url-safe, self-describing string.

Advanced: the five W’s of an id

A good identifier answers five questions at once. What kind of thing is it — the namespace says so. When was it made — the timestamp bits say so, to the millisecond. Where was it made — the worker bits name the machine or process. Which one within that millisecond — the sequence bits disambiguate. And why not a counter: because a counter needs one writer, and a distributed system has many. A Snowflake lets every worker mint ids on its own and still keeps them globally sortable, because time is in the high bits.

For the portal, that means a record can be sorted, paginated, and range-queried by time without a separate created_at column, and a service can shard by worker or route by namespace without ever parsing the payload. The same id is the key the page registry stores, the value the trie hashes, and the stamp printed at the foot of this page.

# EchoData mints one, the portal brands it for the wire
snowflake = EchoData.Snowflake.generate(worker_id: 7)
# => 274557032793636864  (a 64-bit integer; time-ordered)

branded   = "TSK" <> EchoData.Base62.encode(snowflake)
# => "TSK0KHTOWnGLuC"  (3-char namespace + 11-char base62)

F4.04–F4.06 · the key

A map hashes a key into a trie; the key was treated as opaque.

F4.07 · the id itself

That key is a branded Snowflake — a timestamped, namespaced, coordination-free integer.

Start with choosing an identifier, then the Snowflake bigint, then branded ids. Predecessor: F4.06 — CHAMP maps. Next module: F4.08 — Branded ids & persistence, where these ids become keys in SQLite, PostgreSQL, and Redis, ahead of the branded CHAMP map of F4.09.

References

Primary sources for this lesson, and where it connects in the course.

Sources

Related in this course