When working with a database, one of the most crucial steps is assigning a unique ID to each record. If you end up with millions of rows, each one still needs a way to be told apart.
It is easy to make, make sure the authority keeps the last ID, and when a new element comes, just increment it.
$$ id_n = id_{n-1} + 1 $$
Let’s assume we have to create a unique ID for cars, but here is the problem: the number of cars and increasing very fast in the current world. For example, if we take the 5-digit car number, possible combinations are 10^5 = 100_000, which is a very small number. Right now, in Uzbekistan, there are millions of cars. But if we expand the digits, it can make it very difficult for cars to wear numbers and very long
So we will optimize it by adding some characters, like letters:
Now we have: 26101010262613 ~ 228 488 000 combinations. It is more than enough for cars
But for billions of rows, it is not
IBM’s System/360 introduced something new: it had a built-in TOD (time-of-day) clock that counted time in 64-bit precision.
Unique ID = timestamp + node-id + sequence
Example: {1715264879123456} + {42} + {7}
Still centralized
Beginning of distributed systems. The question was:
How can two computers that never communicate still generate IDs that won’t collide later? This was a brand-new challenge. You couldn’t rely on a central server anymore—machines had to create IDs independently.