¿Qué es un UUID y cuándo deberías usar uno?

Probablemente hayas visto una cadena como f47ac10b-58cc-4372-a567-0e02b2c3d479 en una URL, una base de datos o un archivo de configuración y te hayas preguntado qué es y por qué es tan larga. Eso es un UUID, y toda su función consiste en ser un identificador único que cualquier máquina puede generar por su cuenta, sin un contador compartido y casi sin posibilidad de chocar con el de otra persona. Saber cómo funciona te dice exactamente cuándo usarlo y cuándo un número simple es la mejor herramienta.

TL;DR: Un UUID es un identificador de 128 bits, que normalmente se muestra como 32 dígitos hexadecimales en cinco grupos (8-4-4-4-12). Existe para que cualquier máquina pueda crear un ID de forma independiente y aun así evitar colisiones, sin un servidor central. Los UUID aleatorios (versión 4) tienen la unicidad prácticamente garantizada. Usa uno para IDs distribuidos o generados en el cliente y para IDs públicos que no deberían ser adivinables; recurre a un entero autoincremental simple cuando una sola base de datos es dueña de las claves.

Qué es realmente un UUID

Un UUID es un valor de 128 bits. Para que esos bits sean legibles, se escriben como 32 dígitos hexadecimales agrupados en 8-4-4-4-12 y unidos por guiones, como 550e8400-e29b-41d4-a716-446655440000. Los guiones no tienen ningún significado; solo dividen la ristra de dígitos. El nombre completo es identificador único universal, y GUID, el término que ves en las herramientas de Microsoft, es lo mismo con otra etiqueta.

El sentido de tantos bits es el rango. Con 128 bits hay aproximadamente 3,4 por 10 elevado a 38 valores posibles, un número tan grande que elegir uno al azar y volver a elegir ese mismo, a efectos prácticos, no va a pasar. Ese espacio enorme es lo que permite que el esquema cumpla su promesa central: que un ID generado en una máquina no choque con uno generado en otra, aunque las dos nunca se hayan coordinado.

Por qué existen los UUID

El problema que resuelven los UUID es generar un identificador sin una autoridad central. Una base de datos clásica reparte IDs desde un único contador: fila 1, fila 2, fila 3, cada número emitido por un servidor que sabe cuál fue el último que dio. Eso funciona de maravilla hasta que tienes muchos servidores, clientes sin conexión o sistemas que deben crear registros sin consultar antes con nadie. Dos de ellos pedirán a la vez “el siguiente número” y chocarán.

Un UUID se salta el contador por completo. En lugar de pedir el siguiente valor a un servidor, una máquina genera un UUID localmente a partir de aleatoriedad o de una marca de tiempo, y confía en el enorme espacio de valores para mantenerlo único. Sin coordinación, sin ida y vuelta, sin un único punto al que todos tengan que preguntar. Un teléfono en modo avión puede crear el ID de un registro, y un servidor puede crear otro, y cuando luego se sincronicen, los dos IDs no chocarán. Esa independencia es toda la razón por la que existe el formato.

¿Qué tan improbable es una colisión, en realidad?

Para un UUID de versión 4, que rellena sus bits con aleatoriedad, una colisión es posible en teoría y despreciable en la práctica. Un UUID v4 fija unos pocos bits para marcar su versión y variante, lo que deja 122 bits aleatorios, es decir, unos 5,3 por 10 elevado a 36 valores distintos. Para tener siquiera una probabilidad de uno en mil millones de un solo duplicado, tendrías que generar del orden de un trillón de UUID.

Dicho en términos cotidianos, podrías generar mil millones de UUID v4 por segundo durante aproximadamente un siglo y aun así sería más probable que ganaras varias veces seguidas un gran sorteo de lotería que ver una sola colisión. Así que, aunque “universalmente único” no es una garantía matemática, la distancia entre la teoría y la realidad es tan amplia que los sistemas en producción tratan los UUID v4 como únicos sin pensarlo dos veces. Puedes crear uno tú mismo con un generador de UUID gratuito en dev.hivly.net y ver el formato directamente.

Las versiones más comunes, y por qué importa la v7

Los UUID vienen en varias versiones, y el dígito con el que empieza el tercer grupo te dice cuál tienes entre manos. Las dos que más te encontrarás son la versión 4 y las versiones basadas en el tiempo. Un UUID de versión 4 se construye a partir de bits aleatorios, así que no lleva ninguna información sobre cuándo o dónde se creó; es pura aleatoriedad dentro de la estructura fija. Esa aleatoriedad es precisamente lo que lo convierte en un buen ID público, ya que no puedes adivinar el siguiente.

La versión 1 es el viejo diseño basado en el tiempo, que mezcla una marca de tiempo con la dirección de red de la máquina, lo que generaba preocupaciones de privacidad porque podía filtrar la identidad del hardware. La versión 7 es la opción moderna basada en el tiempo, y corrige la debilidad interesante de la v4: el orden. Un UUID v7 coloca una marca de tiempo en milisegundos al principio, de modo que ordenar UUID v7 como texto los ordena por hora de creación. Eso suena menor, pero importa mucho para las bases de datos, donde las claves v4 aleatorias dispersan las inserciones por todo un índice y las claves v7 caen en orden, lo que mantiene el índice ordenado y más rápido de escribir.

Cuándo usar un UUID, y cuándo no

Recurre a un UUID cuando los IDs nacen en muchos lugares que no pueden compartir un contador: servicios distribuidos, varias bases de datos, o clientes que generan claves sin conexión antes de sincronizar. Usa uno cuando quieras un ID de cara al público que no revele cuántos registros tienes ni permita que alguien recorra la secuencia. Una URL que termina en /orders/8 invita a adivinar /orders/9; una URL que termina en un UUID no.

Un entero autoincremental simple es la opción más sencilla, y a menudo mejor, cuando una sola base de datos es dueña de todos los IDs. Los enteros son diminutos al lado de un valor de 128 bits, se indexan más rápido, son fáciles de leer y escribir, y se ordenan de forma natural. El coste de un UUID es real: ocupa más espacio, es más lento de indexar cuando es aleatorio, y nadie lo lee en voz alta con comodidad. Así que la decisión no es “los UUID son modernos, los enteros son viejos”. Tiene que ver con quién crea los IDs y con si el valor necesita seguir siendo opaco. Si un solo servidor es dueño de las claves y estas pueden ser secuenciales, usa un entero. Si la creación está repartida o el ID no debe ser adivinable, usa un UUID, y prefiere la v7 cuando además quieras que se ordenen por tiempo.