In a single database where you can just use an auto_increment column, distributed systems have multiple nodes working simultaneously. If they don’t coordinate perfectly, they might accidentally hand out the same ID to two different users.

To solve this, we need a strategy that ensures IDs are

• Unique and sortable.
• The system should be able to generate 10,000 IDs per second.
• Max 64 bits.

Common Approaches#

UUID#

• UUIDs are 128-bit number generated locally by each node using a combination of time, node ID, and randomness.
• Each server will generate unique number without any coordination.
• They are bulky (128 bits) and not naturally sortable (they’re random) by time, which can hurt database performance.

Ticket Server#

• We can use a centralized server (ticket server) which will generate IDs for all the other servers.
• The ticket server becomes a “Single Point of Failure” (if it goes down, nobody gets an ID).

Twitter Snowflake Approach#

• In this approach, we can divide our unique ID in multiple parts. Like,
  • Timestamp
  • Machine ID
  • Unique value
• For tiemstamp, we can define 0 value to whatever we want. It can be UNIX epoch, snowflake epoch (Nov 04, 2010, 01:42:54 UTC), or our own custom epoch.
• Machine id is the identifier of the machine which has generated the ID.
• Unique value is the unique value, incremental or random, generated by the machine.
• The more bits we allocate for any section, we will get more values for that. For example, if we have more machines which might generate IDs, we have to allocate more bits for machine section.