Splync's Dual Identifier Approach: UUID and Auto-Incremented Int

In Splync’s database, every user — and every project — is identified by two different IDs: a UUID and an auto-incremented integer. The auto-incremented integer is the one most people are familiar with — it’s just a counter: 1, 2, 3, and so on. Splync uses these integers inside the server database to organize almost every table because they are simple, fast, and efficient for joins. However, we never expose these internal numbers to the app. For example, if you happened to be the 42nd user to sign up, your internal ID in the database would be 42. But your iOS app never sees “42.” Instead, the app uses a UUID to represent you. We apply the same approach to projects — a project ID might be "7" inside the database, but the app always refers to it using a long UUID.

UUID stands for Universally Unique Identifier. Splync uses version 4, variant 1 UUIDs, compliant with RFC 4122 — one of the most widely adopted standards. It is a randomly generated string, which looks like 949ca11c-a6ed-48a3-b40a-fa9727494917. A UUID is typically written as 32 hexadecimal characters divided into five sections separated by hyphens. It’s designed to be globally unique, meaning it won’t collide even across different servers or databases. Mathematically, there are about 16^32 = 2^128 possible combinations. However, since six bits are reserved to indicate the variant and version, the total number of distinct version-4, variant-1 UUIDs is roughly 2^122, or about 5.3 x 10^36 — an astronomically large number ensuring practical uniqueness.

Each pair of UUIDv4s has about a 1 in 5.3 × 10^36 chance of matching. That number is so small it almost refuses to exist in the human imagination. To picture it, imagine rolling 47 dice at once. The odds of getting all ones — every single die showing “1” — is about 1 in 6^47, or roughly 1 in 3.7 × 10^36. That’s the same order of magnitude as a UUID collision. Now, imagine every person on Earth — about eight billion of us — rolling those 47 dice every millisecond for a trillion years. That’s about 2.5 × 10^32 total attempts. Even after all that, the chance of someone, somewhere, getting 47 ones at once would still be only one in ten thousand. That’s how unlikely it is for two UUIDv4s to collide. It’s not “rare.” It’s cosmically absurd — the sort of coincidence that would make mathematicians drop their coffee and check the universe for bugs.

At first glance, generating a UUID might seem simple — after all, it’s just a random-looking alphanumeric string. But try writing one yourself with pen and paper. You can jot down 36 characters, sure, yet if you repeat the exercise thousands of times, clear patterns will emerge. Maybe you favor certain digits like 3 or 8, and rarely use letters like x. A computer can detect those biases instantly. A malicious hacker could analyze your habits and narrow down your “random” secret string within a day. Then, what if you also turn to a computer and call rand(), the classic random function, to generate each digit. That’s better — but not good enough. Many "random" number generators in common programming environments are pseudorandom, meaning they follow a predictable mathematical sequence starting from an internal seed, which is typically based on the system time. If someone discovers or guesses that seed, they can reproduce every value your generator ever produced.

Perfect randomness doesn’t really exist — just as a perfect die doesn’t exist, or a perfectly random throw of dice doesn’t exist. Every physical or digital process follows some underlying rules. Still, mathematicians and engineers have spent decades designing algorithms that come as close as possible to true randomness. When Splync creates a new version-4 UUID, it doesn’t simply “pick numbers at random” like rolling dice. It asks the operating system for tiny traces of unpredictability — for example, the precise moment your CPU finishes a task, faint electrical noise inside the hardware, or background timing fluctuations in memory. These fragments of entropy are collected and mixed into 128 bits of data — a long sequence of ones and zeros. The result is a code that is practically impossible to guess or repeat for the app users or potential malicious attackers.

Splync uses UUIDs for sensitive identifiers such as user IDs and project IDs, because they are extremely random and secure. At the same time, inside its server, Splync converts those UUIDs into auto-incremented integers for faster search and analytics on large datasets. This dual-identifier approach strikes a balance between safety and convenience — external privacy with internal performance. Splync’s goal is to be a stress-free, simple, and secure budget-tracking app. Behind the visible UI, we continue refining our architecture to keep things smooth, safe, and quietly smart.