Comparing All Seven Approaches

Why this matters: the scorecard is the artifact to carry out of this chapter. Being able to reproduce it — and explain why each cell is what it is — is the whole deliverable.

Key takeaway

No approach is best in every column. Range handler wins on uniqueness without ordering; Snowflake is the practical choice when you need both; TrueTime is the only clean sweep, and it costs hardware most organizations cannot justify.

The complete scorecard

Approach	Scalable	64-bit numeric ID	Causality maintained
Using UUID
Using a database
Using a range handler
Using UNIX time stamps	weak		weak
Using Twitter Snowflake			weak
Using vector clocks	weak	can exceed
Using TrueTime

Choosing in practice

Situation	Choose	Why
No size constraint, want zero coordination	UUID	Nothing to depend on; a partitioned server still generates valid IDs
Need compact unique keys, ordering irrelevant	Range handler	All four requirements, amortized coordination
Need compact, unique, and roughly time-sortable	Snowflake	The practical default — good enough ordering at no coordination cost
Need provable causality in a small cluster	Vector clocks	Only approach that detects concurrency without special hardware
Need strict external consistency, have the budget	TrueTime	Bounded, explicit uncertainty

For most systems the answer is Snowflake or a Snowflake variant. It is the design that trades a weak causality guarantee — good enough for feeds, tracing, and last-write-wins — for compactness, throughput, and zero coordination.

Six lessons that generalize

Lesson	Detail
Duplicates are dangerous	Duplicate identifiers can cause critical errors — duplicate payments, for instance
Probabilistic vs deterministic	UUIDs offer probabilistic uniqueness; deterministic uniqueness often requires slower consensus mechanisms
Size costs throughput	Large keys slow down database updates; identifiers should be compact
IDs leak information	Random bits prevent external parties from guessing business metrics such as order volume
Counters aren't free	Simple counters are faster than timestamps but require persistent storage, creating bottlenecks and SPOFs
Sortable IDs create hotspots	Monotonically increasing IDs create hotspots in distributed databases like Spanner, reducing performance

The cost of strict global ordering

Enforcing a strict global order on events is costly in distributed systems. Centralized auto-increment is simple on one node but requires distributed consensus across many, which increases latency and coordination overhead.

Concretely: Google Spanner reports that single-row read-modify-write transactions can limit sequence generation to approximately 100 operations per second.

Read that against the requirement of one billion per day — roughly 11,600 per second. A strictly ordered global counter is two orders of magnitude short of the target.

Relaxing strict global ordering constraints can significantly improve throughput and reduce coordination costs. That is the sentence to remember: the reason Snowflake wins in practice is that it gives up perfect ordering to escape consensus entirely.

Key takeaway

Every column in the scorecard trades against another: size against causality, ordering against hotspots, determinism against coordination. The design skill is knowing which guarantee your system actually needs and refusing to pay for the rest.

Interview signal by level

Level	What a strong answer sounds like
L4	Names one approach and stops.
L5	Compares a few: "UUIDs are too big, a central database is a SPOF, so Snowflake — compact and time-sortable."
Staff+	Walks the progression and prices the guarantee: "each approach fixes the last one's failure. Snowflake is the practical answer because strict global ordering needs consensus, and Spanner reports around 100 ops/sec for that — two orders of magnitude below what we need. So I'd take weak ordering deliberately."

Next: the whole thing under interview conditions.