SoupCalc

Gerador de Snowflake ID: O Identificador Distribuído de 63 Bits do Twitter

O Que É um Snowflake ID?

Um Snowflake ID é um inteiro de 63 bits usado para gerar identificadores únicos em um sistema distribuído sem um ponto de coordenação central. O Twitter desenvolveu o formato em 2010 para substituir sequências de autoincremento de banco de dados que não conseguiam escalar em dezenas de servidores de aplicação gravando em clusters MySQL fragmentados. Cada Snowflake ID é um inteiro de 64 bits com sinal, onde o bit mais significativo é sempre zero, deixando 63 bits de carga útil divididos em quatro campos: um offset de timestamp de 41 bits, um identificador de datacenter de 5 bits, um identificador de máquina de 5 bits e um número de sequência de 12 bits. Esse layout permite que um único nó de serviço Snowflake gere até 4.096 IDs únicos por milissegundo, conferindo ao sistema uma vazão teórica de milhões de IDs por segundo em uma implantação com centenas de processos de trabalho.

Os Snowflake IDs são monotonicamente crescentes — cada novo ID é maior que o anterior dentro do mesmo epoch — mas não são estritamente sequenciais entre nós. Duas máquinas operando no mesmo milissegundo produzirão IDs que se intercalam, o que é uma troca deliberada: o esquema sacrifica a ordenação perfeita em troca de independência operacional absoluta. Cada trabalhador precisa apenas saber seu próprio número de datacenter e máquina, além da hora atual, para produzir um identificador globalmente único sem jamais consultar um par ou um serviço de bloqueio.

Anatomia do Identificador de 63 Bits

O Snowflake ID é um inteiro de 63 bits composto pelos seguintes campos, do mais significativo para o menos significativo:

  • Timestamp de 41 bits — milissegundos decorridos desde um epoch personalizado.
  • ID de datacenter de 5 bits — identifica o datacenter físico que hospeda o trabalhador.
  • ID de máquina de 5 bits — identifica o host ou processo individual dentro daquele datacenter.
  • Número de sequência de 12 bits — um contador por milissegundo que é zerado quando o relógio avança.

A frase exata que descreve esse layout é: um timestamp de 41 bits, datacenter de 5 bits, máquina de 5 bits e sequência de 12 bits. Juntos, esses campos ocupam 63 bits, com o bit de sinal líder definido como zero para que o ID caiba confortavelmente em um inteiro de 64 bits com sinal em linguagens como Java e C#.

O Epoch do Twitter e o Componente de Timestamp

Todo Snowflake ID carrega um offset de timestamp medido a partir de um epoch personalizado: 1288834974657 milissegundos. Esse valor corresponde a aproximadamente 2010-11-04T04:42:54.657Z e foi escolhido para se alinhar com o início da implantação interna do Snowflake no Twitter. Usar um epoch personalizado em vez do epoch Unix significa que o campo de timestamp de 41 bits pode representar um intervalo de aproximadamente 69 anos antes de transbordar. O valor máximo de timestamp que o campo pode conter é 2^41 menos 1, ou 2.199.023.255.551 milissegundos — cerca de 69,7 anos após o epoch, o que empurra a data de rolagem para a década de 2080.

Para codificar um timestamp, subtraia o epoch dos milissegundos atuais do epoch Unix e, em seguida, desloque o resultado 22 bits para a esquerda para abrir espaço para os três campos inferiores. Qualquer timestamp de entrada anterior ao epoch é inválido e deve ser rejeitado.

Identificação de Nó por Datacenter e Máquina

O campo de datacenter de 5 bits e o campo de máquina de 5 bits aceitam, cada um, valores de 0 a 31, totalizando 1.024 identificadores de nó únicos em uma implantação. Um trabalhador recebe um ID de datacenter e um ID de máquina na inicialização, normalmente por meio de um arquivo de configuração, um serviço de coordenação como o ZooKeeper ou um argumento de linha de comando. A atribuição deve ser única dentro da frota: dois trabalhadores que compartilham o mesmo par (datacenter, máquina) produzirão IDs colidentes, a menos que seus relógios estejam fora de fase.

Esses campos são inseridos no ID deslocando o valor de datacenter 17 bits para a esquerda e o valor de máquina 12 bits para a esquerda e, em seguida, aplicando um OR bit a bit dos valores deslocados no inteiro de 63 bits. O total de 1.024 nós é suficiente para a maioria das implantações do mundo real, mas ambientes que precisem de mais de 1.024 trabalhadores podem tomar bits emprestados do campo de sequência ou do campo de timestamp, ao custo da vazão ou do alcance do epoch.

O Contador de Sequência e os Limites do Relógio

O campo de sequência de 12 bits é o cavalo de batalha do design Snowflake. Ele vai de 0 a 4.095 e incrementa em um para cada ID gerado dentro do mesmo milissegundo. Quando a sequência atinge 4.095, o trabalhador entra em um laço de espera ocupada até que o relógio do sistema avance para o próximo milissegundo, momento em que a sequência é zerada e a geração é retomada. Isso confere a um único nó uma taxa máxima de rajada de 4.096 IDs por milissegundo.

A deriva do relógio e o retrocesso do relógio são os dois modos de falha mais significativos do algoritmo Snowflake. Se o relógio do sistema retroceder — seja por uma correção NTP, uma migração de máquina virtual ou uma alteração manual — um trabalhador poderá gerar um ID com um timestamp menor que o último que produziu, quebrando a garantia de unicidade. A mitigação padrão é interromper a geração de IDs e lançar um erro quando o retrocesso do relógio for detectado, recusando-se a atender requisições até que o relógio alcance o último timestamp registrado. Uma implantação que não possa tolerar tempo de inatividade deve considerar um serviço de tempo dedicado ou uma camada de relógio lógico.

Exemplo Prático

Considere os seguintes valores de entrada: um timestamp do epoch Unix de 1700000000000 milissegundos, um ID de datacenter de 7, um ID de máquina de 13 e um número de sequência de 4095.

Codificação. Primeiro, calcule o offset de timestamp: 1700000000000 menos o epoch Snowflake 1288834974657 é igual a 411165025343. Desloque esse offset 22 bits para a esquerda para obter 1724551110456246272. Desloque o valor de datacenter 7 em 17 bits para a esquerda para obter 917504. Desloque o valor de máquina 13 em 12 bits para a esquerda para obter 53248. O número de sequência não requer deslocamento. Combine os quatro termos com OR bit a bit para produzir o Snowflake ID final: 1724551110457221119.

Decodificação. Para recuperar os campos originais do ID 1724551110457221119, mascare os 12 bits mais baixos para extrair a sequência: 4095. Desloque 12 bits para a direita e mascare os 5 bits mais baixos para recuperar o ID de máquina: 13. Desloque 17 bits para a direita e mascare os 5 bits mais baixos para recuperar o ID de datacenter: 7. Desloque 22 bits para a direita para obter o offset de timestamp: 411165025343. Adicione o epoch 1288834974657 para recuperar o timestamp original do epoch Unix: 1700000000000.

O ciclo completo é exato porque cada campo cabe dentro de sua largura de bits alocada e nenhuma informação é perdida durante a codificação.

Precisão e Limitações

O esquema de codificação Snowflake é determinístico e reversível, desde que todas as entradas estejam dentro de seus intervalos válidos. O offset de timestamp deve ser um inteiro não negativo de 41 bits; os IDs de datacenter e de máquina devem estar no intervalo de 0 a 31; e a sequência deve estar no intervalo de 0 a 4.095. Qualquer entrada fora desses limites é rejeitada como inválida.

O esquema não leva em conta segundos bissextos nem precisão inferior a milissegundos. Ele depende do relógio do sistema host, que pode sofrer deriva ou ser ajustado por processos externos. Em implantações onde o relógio do sistema é adiantado por um grande salto NTP, o campo de offset avançará corretamente, mas o contador de sequência terá ficado ocioso durante o intervalo, deixando um período de IDs não emitidos. Isso é inofensivo para a unicidade, mas cria uma descontinuidade na linha do tempo dos IDs.

Trabalhadores em partição de rede que compartilham a mesma tupla (datacenter, máquina) produzirão IDs colidentes se estiverem ativos concorrentemente. O espaço de identificadores fornece 1.024 slots de nó únicos, e exceder essa contagem requer uma variante de layout de bits personalizada.

Fontes

Registro Editorial

Este artigo descreve o formato Snowflake ID conforme definido na implementação de referência do Twitter de 2010. O layout de bits e o valor do epoch são extraídos diretamente do código-fonte Scala de código aberto. O exemplo prático foi verificado com um cálculo manual que codifica e decodifica os mesmos valores para confirmar o ciclo completo. A discussão sobre retrocesso do relógio e limites de nós reflete a experiência operacional documentada na literatura de engenharia sobre geração de IDs distribuídos.

O artigo não aborda implementações de terceiros ou variantes que alteram o layout de bits — como aquelas que usam um ID de máquina de 10 bits, um epoch diferente ou um campo de ID de trabalhador obtido de um serviço de coordenação. Essas variantes estão fora do escopo da especificação original do Snowflake. Autor: Equipe Editorial do SoupCalc Última revisão: 11 de agosto de 2026.