Gerador de Snowflake ID

Snowflake ID: 64 bits de identidade distribuída

O Snowflake foi criado pelo Twitter em 2010 para substituir chaves primárias auto-incremento após a empresa fragmentar sua frota MySQL. Objetivo: produzir IDs únicos de 64 bits, ordenados por tempo, sem falar com um servidor central. 64 bits cabem confortavelmente em um BIGINT SQL — metade do tamanho de um UUID de 128 bits — e continuam numéricos, o que importa para linguagens sem inteiros nativos de 128 bits.

Layout de bits (Twitter original)

 1 bit  | 41 bits        | 5 bits     | 5 bits   | 12 bits
 sinal  | timestamp ms   | datacenter | máquina  | sequência
 (0)    | desde epoch    | id (0-31)  | id       | (0-4095)

O epoch do Twitter começa em 1288834974657 (4 de novembro de 2010). Quarenta e um bits de milissegundos dão ao formato uma vida útil de 2⁴¹ ms ≈ 69,7 anos antes de esgotar o campo de timestamp. A sequência de 12 bits incrementa dentro do mesmo milissegundo, então uma única máquina pode cunhar 4.096 IDs por milissegundo. Multiplicado por 32 máquinas × 32 datacenters, o design original chega a aproximadamente 4,19 milhões de IDs por milissegundo globalmente.

Forks e variantes

• Discord — mesmo formato, epoch customizado (1420070400000, 1º de janeiro de 2015). Para ler o timestamp: (snowflake >> 22) + 1420070400000.
• Instagram — substitui o machine ID por um schema_id lógico para que o ID possa ser roteado de volta para o shard Postgres correto.
• MongoDB ObjectId — ideia parecida (timestamp + máquina + contador) mas com 12 bytes, não 8, então não é tecnicamente um Snowflake.
• Sonyflake, TinyID, Seata — ports da comunidade ajustando a alocação de bits para maior throughput ou vida útil mais longa.

Trade-offs importantes

Vantagens: 64 bits (metade do armazenamento do UUID), naturalmente ordenado por tempo, sem coordenador central, throughput muito alto. Desvantagens: depende de relógio sincronizado — NTP é obrigatório — e cada nó precisa de um machine/worker ID único atribuído fora de banda (via config, Zookeeper, etcd, ou uma chamada de registro no startup).

Perguntas frequentes

Como as máquinas geram IDs sem servidor central? Cada nó tem um worker ID único. Os demais campos (timestamp + sequência) são locais, então dois nós com worker IDs diferentes não podem colidir.

E se dois nós tiverem o mesmo worker ID? Colisões são garantidas dentro do mesmo milissegundo. A atribuição de worker ID é o problema operacional mais difícil do Snowflake — a maioria das implementações em produção usa um serviço de coordenação (Zookeeper, etcd) ou um arquivo de configuração estático.

É seguro expor Snowflake em URLs públicas? Ele vaza o timestamp de criação e o layout de shards. Evite em URLs que não devam revelar contagem de usuários, hora de cadastro ou topologia de backend — use um ID aleatório nesses casos.