Por qué los UUID prácticamente nunca colisionan (aunque no se compruebe)
Los sistemas generan UUID aleatorios constantemente sin coordinación central ni comprobación de duplicados, y funciona. La paradoja del cumpleaños explica por qué esa es en realidad una apuesta razonable.
· 4 min de lectura
Una confianza sorprendente depositada en un número aleatorio
Un UUID aleatorio estándar se genera de forma independiente, por cualquier cantidad de sistemas totalmente sin coordinar, sin ninguna autoridad central que reparta el siguiente identificador disponible y sin ninguna comprobación contra una lista de identificadores ya en uso — y a pesar de eso, las colisiones son, a efectos prácticos, algo que nunca ocurre. Esa es una afirmación genuinamente atrevida que descansa por completo en la probabilidad en lugar de en la coordinación, y entender por qué se sostiene requiere el mismo fragmento de matemática contraintuitiva que explica un acertijo mucho más famoso: cuán pocas personas necesitan estar en una sala antes de que sea probable que dos de ellas compartan cumpleaños.
La paradoja del cumpleaños, brevemente
La paradoja clásica del cumpleaños pregunta cuántas personas necesitan reunirse en una sala antes de que haya más de un 50 por ciento de probabilidad de que dos compartan cumpleaños, y la respuesta — solo 23 personas, frente a 365 cumpleaños posibles — sorprende a la mayoría de la gente, que intuitivamente espera que el número esté mucho más cerca de 365. La razón por la que la respuesta real es tan pequeña es que la comparación relevante no es "¿alguna persona específica comparte mi cumpleaños?" sino "¿algún par, de entre todos los pares posibles en la sala, comparte cumpleaños?" — y el número de pares posibles crece muchísimo más rápido que el número de personas, ya que con 23 personas ya hay 253 pares distintos, cada uno una oportunidad independiente de coincidencia. Este patrón matemático exacto — el número de oportunidades de comparación crece de forma cuadrática mientras el número de elementos solo crece de forma lineal — se llama el problema del cumpleaños, y se aplica directamente a cualquier situación que involucre valores aleatorios extraídos de un espacio fijo y comprobados para detectar duplicados, y los UUID encajan perfectamente ahí.
Aplicando la misma matemática a un identificador aleatorio de 128 bits
Un UUID aleatorio estándar (versión 4) extrae de un espacio de 122 bits genuinamente aleatorios — un puñado de los 128 bits totales están fijados por la propia especificación del formato para identificar la versión — lo que significa que el número total de valores posibles es 2 elevado a 122, un número casi incomprensiblemente grande. Aplicando el mismo razonamiento de la paradoja del cumpleaños usado para el ejemplo de los 365 días, pero escalado a ese espacio muchísimo mayor, se obtiene el punto en el que una colisión se vuelve probable: se necesitarían generar aproximadamente 2,7 trillones de UUID antes de que la probabilidad de que dos colisionen suba a cerca del 50 por ciento — para dar una idea de la escala, eso es más UUID de los que hay granos de arena estimados en todas las playas de la Tierra. Un solo sistema, o incluso una gran cantidad de sistemas combinados, generando UUID a cualquier tasa realista del mundo real, tardaría un tiempo que supera con creces la edad del universo en acercarse a ese umbral, que es la base matemática real para tratar las colisiones de UUID como algo que no necesita comprobarse en la práctica.
Por qué v7 cambia la propiedad de ordenación sin tocar en absoluto esta matemática
UUID versión 7, estandarizado más recientemente específicamente para producir identificadores que se ordenan de forma aproximadamente cronológica, lo consigue colocando una marca de tiempo con precisión de milisegundos en los bits iniciales del identificador, en lugar de llenar todo el valor con datos aleatorios como hace la versión 4. Esto podría sonar como si debilitara la garantía de resistencia a colisiones, ya que ahora parte del valor es predecible en lugar de aleatorio — pero los bits restantes siguen llenándose con la misma cantidad de datos genuinamente aleatorios que antes, y como dos UUID generados en el mismísimo milisegundo todavía necesitan que su resto aleatorio coincida exactamente para colisionar, la resistencia práctica a colisiones se mantiene comparable a la de la versión 4 para cualquier tasa de generación realista. Lo que realmente cambia v7 es una propiedad distinta y sin relación — el orden de clasificación — no la matemática de colisiones aquí discutida en absoluto, y merece la pena mantener los dos conceptualmente separados: la unicidad viene del mero tamaño del espacio aleatorio, mientras que la ordenabilidad viene de dónde se sitúa la marca de tiempo dentro del valor.
Qué compra realmente esta confianza en la probabilidad pura
Como la probabilidad de colisión es genuinamente, no solo superficialmente, insignificante, los sistemas pueden generar identificadores completamente independientes — una app móvil funcionando sin conexión de red, una función sin servidor que arranca y desaparece en milisegundos, mil instancias de microservicio paralelas ejecutándose simultáneamente — con cero coordinación entre ellas y sin ningún registro central que rastree lo que ya se ha emitido, y aun así tener una expectativa matemáticamente sólida de que dos de esos identificadores nunca colisionarán. Esa es precisamente la propiedad que un identificador secuencial emitido centralmente nunca podría ofrecer sin una autoridad coordinadora compartida ralentizándolo todo, y es la razón completa por la que los UUID aleatorios se convirtieron en la elección por defecto para sistemas distribuidos que necesitan identificadores a un ritmo que ningún paso de coordinación podría seguir.