Arquitetura de software · Dados · 5 min de leitura
IDs únicos em sistemas distribuídos: UUID, Snowflake e ULID
Gerar identificadores sem um contador central: aleatórios, ordenados pelo tempo, curtos — e o impacto de cada escolha no banco.
Arraste para o lado para ver o diagrama inteiro.
Por que não um contador
O auto-incremento de um único banco vira gargalo e ponto único de falha quando há várias instâncias ou bancos particionados — e expõe quantos registros você tem. As alternativas geram IDs localmente sem colisão.
As opções
- UUID v4: 122 bits aleatórios; colisão desprezível, mas a ordem aleatória espalha inserções pelo índice e piora o desempenho de escrita.
- UUID v7 (RFC 9562) e ULID: começam pelo tempo, então são ordenáveis e amigáveis a índices, mantendo a parte aleatória.
- Snowflake: 64 bits (tempo + máquina + sequência), cabe num inteiro e é ordenável; precisa atribuir IDs de máquina e lidar com relógio que volta.
- Blocos de IDs: um serviço central entrega faixas (1–1000) para cada servidor.
Como escolher
Para a maioria dos sistemas, UUID v7 é um bom padrão: sem coordenação, ordenável e suportado por bancos e bibliotecas. Para URLs curtas, codifique em base62. Se o ID não deve revelar a ordem de criação, use aleatório.
Em resumo
- Contador central não escala nem esconde volume.
- UUID v4 é aleatório e ruim para índices.
- UUID v7/ULID/Snowflake são ordenados pelo tempo.
- UUID v7 é um bom padrão hoje.