Approach 4: UNIX Timestamps
Why this matters: this is the first attempt at time-ordered IDs, and it fails on arithmetic you can do in your head. That makes it the cleanest possible setup for Snowflake.
Key takeaway
UNIX timestamps offer millisecond granularity. An ID-generating server producing one ID per millisecond yields 1,000 identifiers per second — which is not enough.
The throughput ceiling
24 hours * 60 min/hour * 60 sec/min * 1000 IDs/sec = 86,400,000 IDs per day
86.4 million per day — less than the one billion per day the requirements demand. The approach misses the scalability target by more than a factor of ten before any other problem appears.
Removing the single point of failure
A single ID generation server introduces a SPOF. Mitigate it by deploying multiple ID generation servers behind a load balancer. To guarantee system-wide uniqueness, each identifier combines the server ID with a UNIX timestamp.
Combining server ID with timestamp fixes cross-server collisions — two servers in the same millisecond produce different IDs because the server component differs.
Pros and cons
| Detail | |
|---|---|
| Pros | Simple, scalable, and supports multiple servers handling concurrent requests |
| Cons | Concurrent events within the same millisecond may receive the same timestamp, resulting in duplicate IDs |
Scorecard
| Unique | Scalable | Available | 64-bit numeric ID | Causality maintained | |
|---|---|---|---|---|---|
| Using UUID | |||||
| Using a database | |||||
| Using a range handler | |||||
| Using UNIX timestamps | weak | weak |
Note it scores weak rather than ✗ on causality: timestamps do convey ordering, just unreliably — subject to the clock drift and skew from the previous lesson.
Key takeaway
Using the clock as the ID caps throughput at the clock's resolution and collides under concurrency. The fix is not a different clock — it is spending some of the 64 bits on distinguishing IDs within a tick.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "Use the timestamp as the ID so it's sortable." |
| L5 | Does the arithmetic: "millisecond granularity is 86.4 million a day, an order of magnitude short of a billion — and two requests in the same millisecond collide." |
| Staff+ | Identifies the real constraint: "the ceiling is clock resolution, not capacity. Adding a server ID fixes cross-server collisions but not two requests hitting one server in the same millisecond — which happens constantly above 1,000 RPS. I need a per-millisecond sequence component." |
Next: spending the 64 bits properly.