SoupCalc

Generador de Snowflake ID: El identificador distribuido de 63 bits de Twitter

¿Qué es un Snowflake ID?

Un Snowflake ID es un entero de 63 bits utilizado para generar identificadores únicos en un sistema distribuido sin un punto central de coordinación. Twitter desarrolló el formato en 2010 para reemplazar las secuencias autoincrementales de bases de datos que no podían escalar entre decenas de servidores de aplicación escribiendo en clústeres MySQL fragmentados. Cada Snowflake ID es un entero de 64 bits con signo donde el bit más significativo siempre es cero, dejando 63 bits de carga útil divididos en cuatro campos: un offset de timestamp de 41 bits, un identificador de datacenter de 5 bits, un identificador de máquina de 5 bits y un número de secuencia de 12 bits. Esta disposición permite que un solo nodo del servicio Snowflake genere hasta 4.096 IDs únicos por milisegundo, lo que otorga al sistema un rendimiento teórico de millones de IDs por segundo en un despliegue de cientos de procesos trabajadores.

Los Snowflake IDs son monótonamente crecientes — cada nuevo ID es mayor que el anterior dentro de la misma época — pero no son estrictamente secuenciales entre nodos. Dos máquinas operando en el mismo milisegundo producirán IDs que se intercalan, lo cual es una concesión deliberada: el esquema sacrifica el orden perfecto a cambio de una independencia operativa absoluta. Cada trabajador solo necesita conocer su propio número de datacenter y de máquina, más la hora actual, para producir un identificador globalmente único sin consultar nunca a un par ni a un servicio de bloqueo.

Anatomía del identificador de 63 bits

El Snowflake ID es un entero de 63 bits compuesto por los siguientes campos, del más significativo al menos significativo:

  • Timestamp de 41 bits — milisegundos transcurridos desde una época personalizada.
  • ID de datacenter de 5 bits — identifica el datacenter físico que aloja al trabajador.
  • ID de máquina de 5 bits — identifica el host o proceso individual dentro de ese datacenter.
  • Número de secuencia de 12 bits — un contador por milisegundo que se reinicia a cero cuando el reloj avanza.

La frase exacta que describe esta disposición es: un timestamp de 41 bits, datacenter de 5 bits, máquina de 5 bits y secuencia de 12 bits. En conjunto, estos campos ocupan 63 bits, con el bit de signo inicial puesto a cero para que el ID quepa cómodamente en un entero de 64 bits con signo en lenguajes como Java y C#.

La época de Twitter y el componente de timestamp

Cada Snowflake ID lleva un offset de timestamp medido desde una época personalizada: 1288834974657 milisegundos. Este valor corresponde aproximadamente a 2010-11-04T04:42:54.657Z y se eligió para alinearse con el inicio del despliegue interno de Snowflake en Twitter. Usar una época personalizada en lugar de la época Unix significa que el campo de timestamp de 41 bits puede representar un rango de aproximadamente 69 años antes de desbordarse. El valor máximo de timestamp que el campo puede contener es 2^41 menos 1, o 2.199.023.255.551 milisegundos — aproximadamente 69,7 años después de la época, lo que pospone la fecha de desbordamiento hasta la década de 2080.

Para codificar un timestamp, se resta la época de los milisegundos actuales de la época Unix y luego se desplaza el resultado 22 bits a la izquierda para hacer espacio a los tres campos inferiores. Cualquier timestamp de entrada anterior a la época no es válido y debe ser rechazado.

Identificación de nodo: datacenter y máquina

El campo de datacenter de 5 bits y el campo de máquina de 5 bits aceptan cada uno valores de 0 a 31, lo que produce un total de 1.024 identificadores de nodo únicos en un despliegue. A un trabajador se le asigna un ID de datacenter y un ID de máquina al iniciarse, normalmente mediante un archivo de configuración, un servicio de coordinación como ZooKeeper o un argumento de línea de comandos. La asignación debe ser única dentro de la flota: dos trabajadores que compartan el mismo par (datacenter, máquina) producirán IDs colisionantes a menos que sus relojes estén desfasados.

Estos campos se insertan en el ID desplazando el valor de datacenter 17 bits a la izquierda y el valor de máquina 12 bits a la izquierda, y luego aplicando OR a los valores desplazados dentro del entero de 63 bits. El número total de nodos de 1.024 es suficiente para la mayoría de los despliegues reales, pero los entornos que necesiten más de 1.024 trabajadores pueden tomar bits prestados del campo de secuencia o del campo de timestamp a costa del rendimiento o del rango de la época.

El contador de secuencia y los límites del reloj

El campo de secuencia de 12 bits es el caballo de batalla del diseño Snowflake. Va de 0 a 4.095 y se incrementa en uno por cada ID generado dentro del mismo milisegundo. Cuando la secuencia alcanza 4.095, el trabajador entra en un bucle de espera activa hasta que el reloj del sistema avanza al siguiente milisegundo, momento en el cual la secuencia se reinicia a cero y la generación se reanuda. Esto otorga a un solo nodo una tasa máxima de ráfaga de 4.096 IDs por milisegundo.

La deriva del reloj y el retroceso del reloj son los dos modos de fallo más significativos del algoritmo Snowflake. Si el reloj del sistema se mueve hacia atrás — ya sea por una corrección NTP, una migración de máquina virtual o un cambio manual — un trabajador podría generar un ID con un timestamp menor que el último que produjo, rompiendo la garantía de unicidad. La mitigación estándar consiste en detener la generación de IDs y lanzar un error cuando se detecta un retroceso del reloj, negándose a atender solicitudes hasta que el reloj alcance el último timestamp registrado. Un despliegue que no pueda tolerar tiempo de inactividad debería considerar un servicio de tiempo dedicado o una capa de reloj lógico.

Ejemplo práctico

Considere los siguientes valores de entrada: un timestamp de época Unix de 1700000000000 milisegundos, un ID de datacenter de 7, un ID de máquina de 13 y un número de secuencia de 4095.

Codificación. Primero se calcula el offset de timestamp: 1700000000000 menos la época Snowflake 1288834974657 es igual a 411165025343. Se desplaza este offset 22 bits a la izquierda para obtener 1724551110456246272. Se desplaza el valor de datacenter 7 17 bits a la izquierda para obtener 917504. Se desplaza el valor de máquina 13 12 bits a la izquierda para obtener 53248. El número de secuencia no requiere desplazamiento. Se combinan los cuatro términos con OR bit a bit para producir el Snowflake ID final: 1724551110457221119.

Decodificación. Para recuperar los campos originales del ID 1724551110457221119, se aplica una máscara a los 12 bits más bajos para extraer la secuencia: 4095. Se desplaza 12 bits a la derecha y se aplica una máscara a los 5 bits más bajos para recuperar el ID de máquina: 13. Se desplaza 17 bits a la derecha y se aplica una máscara a los 5 bits más bajos para recuperar el ID de datacenter: 7. Se desplaza 22 bits a la derecha para obtener el offset de timestamp: 411165025343. Se suma la época 1288834974657 para recuperar el timestamp original de época Unix: 1700000000000.

El viaje de ida y vuelta es exacto porque cada campo cabe dentro de su ancho de bits asignado y no se pierde información durante la codificación.

Precisión y limitaciones

El esquema de codificación Snowflake es determinista y reversible siempre que todas las entradas se encuentren dentro de sus rangos válidos. El offset de timestamp debe ser un entero no negativo de 41 bits; los IDs de datacenter y de máquina deben estar en el rango de 0 a 31; y la secuencia debe estar en el rango de 0 a 4.095. Cualquier entrada fuera de estos límites se rechaza como no válida.

El esquema no contempla los segundos intercalares ni la precisión por debajo del milisegundo. Depende del reloj del sistema host, el cual puede derivar o ser ajustado por procesos externos. En despliegues donde el reloj del sistema se adelanta mediante un gran salto NTP, el campo de offset avanzará correctamente, pero el contador de secuencia habrá estado inactivo durante el intervalo, dejando un período de IDs no emitidos. Esto es inofensivo para la unicidad, pero crea una discontinuidad en la línea temporal de los IDs.

Los trabajadores particionados por red que compartan la misma tupla (datacenter, máquina) producirán IDs colisionantes si alguna vez están activos simultáneamente. El espacio de identificadores proporciona 1.024 ranuras de nodo únicas, y superar esa cantidad requiere una variante personalizada de la disposición de bits.

Fuentes

Registro editorial

Este artículo describe el formato Snowflake ID tal como se definió en la implementación de referencia de Twitter de 2010. La disposición de bits y el valor de la época se extraen directamente del código fuente Scala de código abierto. El ejemplo práctico se verificó con un cálculo manual que codifica y decodifica los mismos valores para confirmar el viaje de ida y vuelta. La discusión sobre el retroceso del reloj y los límites de nodos refleja la experiencia operativa documentada en la literatura de ingeniería sobre generación de IDs distribuidos.

El artículo no cubre implementaciones de terceros ni variantes que alteren la disposición de bits — como aquellas que usan un ID de máquina de 10 bits, una época diferente o un campo de ID de trabajador obtenido de un servicio de coordinación. Esas variantes quedan fuera del alcance de la especificación original de Snowflake. Autor: Equipo editorial de SoupCalc Última revisión: 11 de agosto de 2026.