Concepto y contexto
UUID define identificadores de 128 bits con layouts estandarizados, pero las versiones incorporan información y propiedades distintas.
v1 se basa en tiempo con campos históricamente ligados al nodo, v4 es aleatorio y v7 combina tiempo Unix en milisegundos con bits aleatorios.
Un buen modelo mental separa el concepto abstracto de su representación concreta y del entorno donde se utiliza. Esa separación evita trasladar automáticamente supuestos válidos en un protocolo, biblioteca o formato hacia sistemas que pueden aplicar reglas o garantías diferentes.
Fundamentos y terminología
Version y variant ocupan bits concretos, por lo que no los 128 bits aportan entropía.
UUID v4 mantiene un espacio aleatorio enorme y v7 tiende a ordenarse por creación, mejorando la localidad de inserción en índices ordenados.
La terminología debe leerse junto con el estándar, versión o contrato que la define, porque palabras parecidas pueden describir propiedades distintas según la capa. Explicitar esas definiciones mejora interoperabilidad, documentación y capacidad para diagnosticar comportamientos inesperados.
Cómo funciona
Generar v4 requiere aleatoriedad adecuada; v7 construye un prefijo temporal y completa el valor con aleatoriedad y reglas para varios ID en el mismo milisegundo.
v1 usa timestamp y clock sequence y puede exponer más metadatos de los necesarios.
En sistemas reales conviene seguir el recorrido de los datos entre capas e identificar qué transformaciones son reversibles, cuáles introducen restricciones y dónde puede perderse información. Así resulta más sencillo razonar sobre responsabilidades entre productores, consumidores, almacenamiento y transporte.
Ejemplo razonado
En una base distribuida v4 evita coordinación y hace muy improbables las colisiones, pero reparte inserciones por el índice.
v7 conserva generación descentralizada y aporta orden temporal aproximado, reduciendo fragmentación sin convertirse en un contador global.
Un ejemplo razonado es reutilizable cuando muestra sus precondiciones e invariantes y no solo el resultado final. Cambiar un supuesto cada vez permite distinguir el comportamiento garantizado por un estándar de las decisiones particulares de una aplicación o implementación.
Errores y conceptos equivocados
Un UUID válido no demuestra que un recurso exista ni autoriza acceso, y la baja probabilidad de colisión no elimina la utilidad de un constraint unique.
Tampoco debe tratarse UUID como secreto porque identificación y autenticación son propiedades distintas.
Muchos fallos nacen de supuestos implícitos entre sistemas aparentemente compatibles que usan versiones, reglas de canonicalización o modelos de tipos diferentes. En interoperabilidad y seguridad conviene especificar y probar entradas anómalas en lugar de tratarlas como casos irrelevantes.
Buenas prácticas y criterios de elección
Elige versión según privacidad, orden, compatibilidad y comportamiento del almacenamiento.
Genera con bibliotecas estándar, usa tipos UUID nativos cuando existan y verifica el orden de bytes antes de depender de una ordenación lexicográfica.
Una práctica robusta combina estándares documentados, bibliotecas maduras, contratos explícitos y pruebas con casos límite representativos. La mejor elección no es siempre la más breve o popular: también cuentan portabilidad, legibilidad, rendimiento, seguridad, evolución y coste operativo.
