Muchas bibliotecas ofrecen una función llamada simplemente “generar UUID”, pero detrás hay versiones con comportamientos distintos. Algunas priorizan aleatoriedad, otras orden temporal y otras determinismo. Esa elección afecta privacidad, índices de base de datos, compatibilidad entre servicios y depuración. Elegir la versión correcta evita que un identificador conveniente se convierta en coste oculto.

Version 4 es el default aleatorio más conocido

UUID v4 rellena la mayor parte del valor con bits aleatorios. Es ampliamente soportado, no revela hora de creación y funciona bien cuando varios productores deben crear IDs sin coordinación. Para identificadores públicos distribuidos, suele ser un punto de partida sólido.

Su desventaja aparece en índices ordenados: las inserciones se reparten por todo el árbol. En sistemas con alto volumen de escritura, eso puede aumentar fragmentación. Antes de descartarlo o adoptarlo, mide el workload real.

Versiones ordenadas por tiempo ayudan a bases de datos

UUID v1 incluía timestamp y datos de nodo, lo que podía filtrar información. Versiones modernas como v7 ordenan aproximadamente por tiempo usando un layout más adecuado y aleatoriedad adicional. Esto mejora locality de índices y facilita ordenar eventos por creación aproximada.

El orden no debe confundirse con cronología legal o financiera. Los relojes se desincronizan y varios generadores pueden emitir IDs en el mismo intervalo. Guarda timestamps explícitos cuando el dominio necesita tiempo real.

Versiones basadas en nombre son deterministas

UUID v3 y v5 producen el mismo resultado para un namespace y name. Son útiles cuando varios sistemas necesitan derivar el mismo ID sin consultar un servicio central. El namespace evita que nombres iguales en dominios distintos choquen entre sí.

El input debe normalizarse de forma idéntica. Mayúsculas, espacios y encoding cambian el resultado. Además, un ID determinista puede revelar que dos registros provienen del mismo source name, así que conviene evaluar privacidad.

No inventes una versión privada sin necesidad

Crear un string con forma de UUID pero reglas propias rompe interoperabilidad. Las bibliotecas, validadores y operadores no sabrán qué propiedades tiene. Si necesitas otro tipo de identificador, quizá ULID, KSUID u otro esquema establecido sea más honesto que un UUID disfrazado.

Usa librerías mantenidas y revisa que generen bits de versión y variante correctos. Un generador basado en timestamp y random débil puede repetir valores bajo concurrencia o entornos clonados.

La política de aceptación debe ser explícita

Un servicio puede generar v7 y aceptar v4 legacy. Otro puede permitir cualquier UUID estándar en entrada, pero emitir solo una versión. Documentar esa política evita errores cuando se integran socios con validadores antiguos.

Los mensajes de error deben distinguir formato inválido de versión no permitida. Así el cliente sabe si debe corregir sintaxis o actualizar compatibilidad.

La migración no debe reescribir identidad antigua

Cambiar la versión preferida no implica reemplazar IDs existentes. Los enlaces, foreign keys, logs y referencias externas dependen de ellos. Normalmente se empieza a generar la nueva versión para registros nuevos y se aceptan valores antiguos indefinidamente.

Una migración que reasigna IDs necesita una razón muy fuerte y un plan de redirects o mappings. El coste de romper identidad suele superar cualquier beneficio estético.

La elección afecta herramientas humanas

UUID v7 se ordena mejor en listados y logs, lo que puede ayudar a soporte. UUID v4 oculta mejor el momento aproximado de creación. Name-based UUID facilita reproducibilidad. Estas diferencias son operativas, no solo teóricas.

Admin panels y logs deben permitir búsqueda exacta, copia segura y contexto adicional. Ninguna versión hace que un identificador largo sea cómodo para humanos sin herramientas.

La privacidad no depende solo de la versión

Un UUID aleatorio puede ocultar la hora de creación, pero el endpoint puede revelar conteos, relaciones o metadata. Un UUID ordenado por tiempo puede ser aceptable para datos internos y no para recursos públicos sensibles. La evaluación debe cubrir todo el flujo.

Si un ID aparece en URLs compartidas, logs de terceros o exports, su versión es solo una parte de la amenaza. Minimización de datos y permisos siguen siendo necesarios.

La compatibilidad externa debe verificarse

Algunos validadores antiguos aceptan solo v4 aunque otros UUID sean estándar. Antes de adoptar una versión nueva, prueba SDKs, bases, gateways y socios. Un rollout gradual evita que una decisión local rompa integraciones aparentemente ajenas.

Las pruebas deben cubrir mezcla de versiones

Durante años pueden convivir IDs antiguos y nuevos. Fixtures, factories y validators deben incluir esa mezcla para evitar que un cambio de generación rompa lectura de datos existentes. Las pruebas también deben comprobar que sorting por UUID no reemplaza timestamps cuando el orden importa.

Benchmark y privacidad completan la decisión

Compara generación, inserciones, tamaño de índices, replication y queries en datos parecidos a producción. Evalúa también qué revela el ID sobre tiempo, origen o volumen. La mejor versión es la que satisface requisitos reales, no la más reciente por sí misma.

Cuando la decisión queda escrita como estándar del sistema, todos los servicios generan y validan de la misma manera. Esa consistencia es tan importante como la versión elegida.