Concepts
Time-sortable IDs (Snowflake layout)
Intuition
Imagine several store cashiers issuing service tickets without talking to each other. To make sure no two cashiers ever hand out the same ticket, each ticket has written on it the time, the cashier's number, and a counter for that instant. Since the time comes first, tickets issued later tend to have a higher number, and nobody had to ask anyone anything to generate them.
How it works
In the 2010 Snowflake code, the 64-bit ID is composed, from the highest bit to the lowest, of a millisecond timestamp (counted from a custom epoch), a 5-bit datacenter ID, a 5-bit worker ID and a 12-bit sequence. Because the timestamp occupies the high bits, IDs generated later tend to be numerically larger; numeric order follows each machine's local clock, and the code that was read makes no finer ordering guarantees across different machines. Within the same millisecond, the sequence tells apart the IDs from the same worker; if it overflows, the generator waits for the next millisecond. Uniqueness across machines is guaranteed if each generator receives a distinct datacenter/worker pair, which the code does not ensure (it only validates the range from 0 to 31 and does not prevent repeated pairs) and which is therefore the operator's responsibility. Uniqueness also depends on the clock: the generator stores the last timestamp used and, if the current clock reads lower, refuses to issue IDs and throws an exception until the clock catches up, preferring to be unavailable rather than risk a duplicate ID. That last timestamp is kept only in memory, so the protection does not cover process restarts. Flickr's alternative is the ticket server: a dedicated database whose client runs REPLACE INTO on a one-row table and reads LAST_INSERT_ID(), with two servers splitting odd and even numbers to tolerate failures; each ID costs a write to a central database, in exchange for sequential, compact numbers.
In practice
When data is spread across many databases and each one's auto-increment column is no longer enough, the timestamp + worker + sequence layout lets each generator create unique, compact keys that are roughly ordered in time, with no coordination at generation time. The operational cost is ensuring distinct worker identifiers and monitoring machine clocks, since a clock that moves backward makes the generator stop issuing IDs. If you prefer sequential numbers and accept one write to a central database per ID, Flickr's ticket server, deliberately simple, is the alternative described in the post.
Use it in a design
Practice the cases that rely on this concept in the System Design school.