https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c
1. Using UUID. 128 Bits
Pros: each application generate independently, if you use a timestamp as first component of ID, the IDs remain time-sorted.
Cons: Requires more storage space (96 bits) to make reasonable uniques, some UUID are completely random and have no natural sort.
2. Use Ticket Server . Use one node to generate Unique Auto-increase ID
Pros: Master-Master, increase ID saved in DB. using MySql auto-increment columns for Primary keys.
Cons: Single point of failure, not suitable for Write per second very high cases. It will be bottleneck.
3. Twitter Snowflake service (open source service)
ID are Unique 64-bit unsiged integers (timestamp + Node ID + sequence number)
Node ID: coordinate by Zookeeper.
Pros: 64-bits, half size of UUID, time can be 1st part which still sortable. Distributed, can survive nodes dying.
Cons: add more complexity (zookeeper, snowflake servers)
4. Instagram build its own solution:
41 bits for time in milliseconds.
13 bits that represent the logical hard ID
10 bits represent an auto-iincrementing sequence modulus 1024. (which means we can generate 1024 IDs, per hard, per millionsecond);