Approche des doubles identifiants de Splync : UUID et Int auto-incrémenté

Dans la base de données de Splync, chaque utilisateur — et chaque projet — est identifié par deux ID différents : un UUID et un entier auto-incrémenté. L’entier auto-incrémenté est celui que la plupart des gens connaissent — c’est juste un compteur : 1, 2, 3, etc. Splync utilise ces entiers dans la base de données du serveur pour organiser presque toutes les tables car ils sont simples, rapides et efficaces pour les jointures. Cependant, nous ne révélons jamais ces numéros internes à l’application. Par exemple, si vous êtes le 42ᵉ utilisateur à vous inscrire, votre ID interne dans la base de données serait 42. Mais votre application iOS ne verra jamais “42.” Au lieu de cela, l’application utilise un UUID pour vous représenter. Nous appliquons la même approche aux projets — un ID de projet pourrait être "7" dans la base de données, mais l'application s'y réfèrera toujours en utilisant un long UUID.

UUID signifie Identifiant Unique Universel. Splync utilise des UUID version 4, variante 1, conformes à la RFC 4122 — l'une des normes les plus adoptées. C'est une chaîne générée aléatoirement, qui ressemble à 949ca11c-a6ed-48a3-b40a-fa9727494917. Un UUID est généralement écrit sous la forme de 32 caractères hexadécimaux divisés en cinq sections séparées par des tirets. Il est conçu pour être unique à l'échelle mondiale, ce qui signifie qu'il ne se heurtera pas, même sur différents serveurs ou bases de données. Mathématiquement, il y a environ 16^32 = 2^128 combinaisons possibles. Cependant, comme six bits sont réservés pour indiquer la variante et la version, le nombre total d'UUID distincts version-4, variante-1 est d'environ 2^122, soit environ 5,3 x 10^36 — un nombre astronomiquement grand garantissant une unicité pratique.

Chaque paire d'UUIDv4 a environ une chance sur 5,3 × 10^36 de correspondre. Ce nombre est si petit qu'il semble presque irréel pour l'imaginaire humain. Pour se le représenter, imaginez lancer 47 dés à la fois. La probabilité d'obtenir que des uns — chaque dé montrant “1” — est d'environ 1 sur 6^47, ou environ 1 sur 3,7 × 10^36. C'est le même ordre de grandeur qu'une collision d'UUID. Maintenant, imaginez que chaque personne sur Terre — environ huit milliards d'entre nous — lance ces 47 dés chaque milliseconde pendant un billion d'années. Cela représente environ 2,5 × 10^32 tentatives au total. Même après tout ça, la probabilité que quelqu'un, quelque part, obtienne 47 uns à la fois serait encore d'une sur dix mille. C'est à quel point il est improbable que deux UUIDv4 se heurtent. Ce n'est pas “rare.” C'est cosmiquement absurde — le genre de coïncidence qui ferait sursauter les mathématiciens de leur café et vérifier l'univers pour y trouver des bugs.

À première vue, générer un UUID peut sembler simple — après tout, c'est juste une chaîne alphanumérique à l'apparence aléatoire. Mais essayez d’en écrire un vous-même avec un stylo et du papier. Vous pouvez noter 36 caractères, bien sûr, mais si vous répétez l'exercice des milliers de fois, des motifs clairs apparaîtront. Vous favorisez peut-être certains chiffres comme le 3 ou le 8, et utilisez rarement des lettres comme x. Un ordinateur peut détecter ces biais instantanément. Un pirate mal intentionné pourrait analyser vos habitudes et réduire votre chaîne secrète “aléatoire” en une journée. Ensuite, que faire si vous vous tournez également vers un ordinateur et appelez rand(), la fonction aléatoire classique, pour générer chaque chiffre. C'est mieux — mais pas suffisant. De nombreux générateurs de nombres "aléatoires" dans les environnements de programmation courants sont pseudorandom, c'est-à-dire qu'ils suivent une séquence mathématique prévisible à partir d'une graine interne, qui est généralement basée sur l'heure du système. Si quelqu'un découvre ou devine cette graine, il peut reproduire chaque valeur que votre générateur a jamais produite.

Une véritable aléatoire n’existe pas vraiment — tout comme un dé parfait n'existe pas, ou un lancer de dé parfaitement aléatoire n'existe pas. Tout processus physique ou numérique suit certaines règles sous-jacentes. Pourtant, les mathématiciens et ingénieurs ont passé des décennies à concevoir des algorithmes qui se rapprochent le plus possible de la véritable aléatoire. Quand Splync crée un nouvel UUID version 4, il ne se contente pas de “choisir des chiffres au hasard” comme si on lançait des dés. Il demande au système d'exploitation des traces infimes d'imprévisibilité — par exemple, le moment précis où votre CPU termine une tâche, le faible bruit électrique à l'intérieur du matériel ou les fluctuations de temps en tâche de fond dans la mémoire. Ces fragments d'entropie sont collectés et mélangés en 128 bits de données — une longue séquence de uns et de zéros. Le résultat est un code pratiquement impossible à deviner ou à reproduire pour les utilisateurs de l'application ou les potentiels attaquants malveillants.

Splync utilise des UUID pour les identifiants sensibles tels que les ID utilisateur et les ID de projet, car ils sont extrêmement aléatoires et sécurisés. En même temps, à l'intérieur de son serveur, Splync convertit ces UUID en entiers auto-incrémentés pour des recherches et analyses plus rapides sur de grands ensembles de données. Cette approche des doubles identifiants établit un équilibre entre sécurité et commodité — la confidentialité externe avec la performance interne. L'objectif de Splync est d'être une application de suivi de budget sans stress, simple et sécurisée. Derrière l'UI visible, nous continuons à affiner notre architecture pour garder les choses fluides, sûres et discrètement intelligentes.