Versions Compared
Version | Old Version 6 | New Version 7 |
---|---|---|
Changes made by | ||
Saved on |
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Tip |
---|
The Framework proposed in this space (Alex Xu) is applied to propose a design : Getting started - a framework to propose... |
Introduction
Step 1 - Understand the problem and establish design scope
Characteristics of unique IDs ? | IDs = unique & sortable |
---|---|
Does ID increment by 1 for each new record ? | ID increments by time, but not necessarily by 1. |
IDs contain numerical values ? | Contain numerical values. |
ID length requirement ? | IDs should fit into 64-bit. |
Scale of the system ? | Able to generate 10000 IDs per second. |
On this page.
Table of Contents |
---|
Step 2 - High-level design
Traditional approach - Non-Distributed System
Approach uses a shared counter, the latter increases at each call.

We can also, generate un ID as a timestamp function.
Shared counter and timestamp function are limited because generate issues :
multiple independent servers can generate the same ID;
the same ID generates for 2 consecutives requests.
Approaches in Distributed system
There are probably 7 options / approaches and here’s below an overall comparison table below.
UUID/GUID | MONGODB | CENTRALIZE MYSQL (FLICKR) | MYSQL: CLUSTER | TWITTER SNOWFLAKE | SONYFLAKE | BAIDU UID GENERATOR | |
---|---|---|---|---|---|---|---|
ORDERED | NO | YES, POSSIBLE | YES | YES | YES, ROUGHLY | YES, ROUGHLY | YES, ROUGHLY |
SCALE | YES | YES | NO | YES, ROUGHLY | YES | YES | YES |
LENGTH (BITS) | 128 | 96 | 64 | 64 | 64 | 63 | 64 |
UNIQUENESS | RARE | NO, POSSIBLE | NO | NO | NO | NO | NO |
SIMPLICITY | YES | YES | YES | NO | NO | NO | NO |
GEO-LATENCY | FAST | FAST | SLOW | FAST, POSSIBLE | FAST | FAST | FAST |
INDEXABLE | HARD | YES | YES | YES | YES | YES | YES |
UUID
Each Web server could contain an ID Generator & the Web Server is responsible for generating IDs independently.

MONGODB
CENTRALIZE MYDQL (FLICKR)
Step 3 - Design deep dive
Alex Xu chooses the Twitter Snowflake approach because of the requirements established above.