E aí bate aquela pergunta clássica:

“Cadê o ID sequencial bonitinho e ordenado?”

Mais do que isso:
Será que esses IDs são performáticos mesmo?
Será que não vão explodir meus índices?
Isso é arquitetura… ou só modinha?

Se essas perguntas já passaram pela sua cabeça, esse artigo é pra você.

Hoje vamos falar sobre identificação de recursos em APIs modernas, com foco em duas estratégias muito comuns:

• IDs sequenciais
• UUIDs (ou UIDs)

Mais importante do que decorar vantagens e desvantagens é entender o impacto arquitetural dessa escolha — porque ela muda, de forma significativa, como seu sistema se comporta, escala e se protege.

O que é um ID, afinal?

Antes de comparar estratégias, vale alinhar o conceito.

Um ID (identificador) é um valor único usado para diferenciar um registro dos outros.
Em uma API, ele é essencial para:

• Buscar recursos
• Atualizar dados
• Referenciar entidades com segurança e precisão

Uma boa analogia é pensar em um CPF ou RG: não importa quantas pessoas tenham o mesmo nome, aquele número identifica uma única pessoa.

Dentro de sistemas, existem várias formas de gerar esse identificador. Neste artigo, vamos focar nas duas mais comuns no dia a dia de quem desenvolve APIs.

IDs sequenciais: o clássico que todo mundo conhece

O ID sequencial é o velho conhecido de quem começou estudando bancos de dados relacionais.

Normalmente ele é:

• Um número inteiro
• Gerenciado pelo próprio banco
• Gerado automaticamente com auto increment

Você insere um registro e pronto: o banco cuida de atribuir o próximo número disponível.

Por que eles são tão populares?

Porque têm vantagens muito claras:

• Alta performance
• Índices extremamente eficientes
• Ordenação natural
• Fáceis de entender
• Leves em termos de armazenamento (4 a 8 bytes)

Em sistemas grandes, com milhões ou bilhões de registros, isso faz muita diferença.

Então… se eles são tão bons, por que não usar sempre?

Onde os IDs sequenciais começam a falhar

Muitas das qualidades dos IDs sequenciais se tornam problemas sérios quando entramos no mundo das APIs públicas e dos sistemas distribuídos.

1. Exposição de informação sensível

Imagine que você cria um usuário e recebe o ID 1234.
Só com isso já dá para inferir muita coisa.

Se a URL for algo como:

/users/1234

Um atacante pode simplesmente tentar:

/users/1235
/users/1236
/users/1237

Se a API estiver mal protegida, você acabou de facilitar:

• ID Enumeration Attacks
• Scraping massivo de dados
• Vazamento de informações sensíveis

Mesmo que exista autenticação, esse padrão já entrega mais informação do que deveria.

2. Inteligência competitiva indesejada

Com IDs sequenciais, alguém consegue inferir:

• Quantos usuários existem
• Quantos pedidos foram feitos
• Ritmo de crescimento do negócio

Isso pode parecer detalhe técnico, mas vira dado estratégico quando exposto.

3. Problemas em sistemas distribuídos

Agora pense em um cenário mais arquitetural.

Você tem:

• Várias instâncias da API
• Todas gravando no mesmo banco
• Alto volume de requisições simultâneas

Nesse cenário, o banco precisa:

• Coordenar quem pega qual ID
• Criar locks
• Sincronizar inserts concorrentes

Isso gera:

• Gargalos
• Perda de performance
• Menos ganho real com escalabilidade horizontal

Ou seja: o banco vira o gargalo do sistema.

UUIDs: identificadores pensados para sistemas distribuídos

Os UUIDs existem desde a década de 80, mas foram padronizados para a internet com a RFC 4122 e evoluíram ao longo do tempo.

A ideia central é simples e poderosa:

Cada sistema pode gerar IDs sem precisar se coordenar com ninguém.

Características principais

• 128 bits
• Representação hexadecimal
• Extremamente baixa chance de colisão
• Geração local, inclusive offline

Isso muda completamente o jogo.

Por que UUIDs funcionam tão bem em APIs modernas?

Vamos revisitar alguns problemas dos IDs sequenciais.

Colisão em ambientes distribuídos? Praticamente inexistente

Cada instância gera seu próprio ID, sem depender do banco.

Geração offline

Perfeito para aplicações que precisam sincronizar dados depois.

Segurança por obscuridade (bem aplicada)

Não dá para “chutar” o próximo ID.

Ideal para logs, eventos e mensageria

Cada evento pode ser identificado globalmente, sem conflito.

Mas… UUIDs são todos iguais?

Não. Existem várias versões, cada uma com características diferentes.

UUID v1

• Baseado em timestamp + MAC address
• Ordenável
• Problema: expõe informações sensíveis

UUID v2

• Inclui ID de usuário e grupo do sistema operacional
• Quase ninguém usa (com razão)

UUID v3 e v5 (determinísticos)

• Baseados em namespace + hash
• Úteis quando você quer gerar sempre o mesmo ID a partir dos mesmos dados
• V3 usa MD5, V5 usa SHA-1

UUID v4 (o mais usado)

• Totalmente aleatório
• Fácil de gerar
• Amplamente suportado
• Problema: não é ordenável → impacta índices

UUID v7 (o novo queridinho)

• Timestamp + aleatoriedade
• Ordenável
• Ótimo para bancos e eventos
• Retrocompatível com versões anteriores

A v7 traz o famoso “melhor dos dois mundos”.

Então UUIDs são sempre melhores?

Não.

Eles também têm trade-offs importantes:

• São maiores (128 bits)
• Impactam índices se mal utilizados
• URLs ficam menos amigáveis
• Mais custo de storage
• Nem todo cenário precisa dessa complexidade

Quando usar UUIDs?

• APIs públicas
• Sistemas distribuídos
• Microsserviços
• Identificação de eventos e logs
• Sincronização entre sistemas
• Geração de IDs offline
• Quando segurança e escalabilidade importam

Quando IDs sequenciais ainda fazem sentido?

• Sistemas pequenos e centralizados
• Dados internos que não são expostos
• Tabelas de domínio
• Conjuntos de dados controlados
• Quando slugs fazem mais sentido (SEO, URLs legíveis)

Conclusão: não existe ID perfeito

A escolha do identificador diz muito sobre o tipo de sistema que você está construindo.

IDs sequenciais são simples, rápidos e eficientes — até o momento em que começam a limitar segurança e escalabilidade.

UUIDs resolvem problemas reais de sistemas modernos, mas trazem novos desafios.

No fim das contas, o papel do arquiteto e do desenvolvedor é entender o domínio, o contexto e os trade-offs.

Não existe bala de prata.
Existe a escolha certa para o seu caso de uso.

The post Como identificar recursos em APIs modernas sem cair em armadilhas appeared first on essencia.dev.

Neste artigo, vamos entender:

• Por que unicidade não é o único requisito de um ID
• As limitações de IDs sequenciais e UUIDs em sistemas distribuídos
• O que são Snowflake IDs e como eles funcionam
• Por que grandes APIs adotam esse modelo
• Quando essa estratégia faz sentido (e quando não faz)

Unicidade é só o requisito mínimo

Quando falamos em identificadores, quase todo mundo concorda em um ponto:

Um ID precisa ser único.

Mas em sistemas reais, distribuídos e em produção, isso está longe de ser suficiente.

Em APIs modernas, bons identificadores também precisam:

• Ser gerados sem coordenação central
• Funcionar bem com múltiplas instâncias
• Não virar gargalo de performance
• Permitir paralelismo
• Não vazar informações sensíveis do negócio
• Ajudar (e não atrapalhar) observabilidade e operação

Ou seja: unicidade é o requisito mínimo, não o objetivo final.

O problema dos sistemas distribuídos

Em arquiteturas distribuídas lidamos com:

• Auto scaling
• Múltiplos serviços
• Concorrência real
• Execução paralela
• Múltiplas regiões
• Infraestrutura dinâmica

Nesse cenário, deixar a geração de IDs:

• centralizada no banco
• dependente de sequência
• ou altamente acoplada a um único ponto

é pedir para criar gargalos.

IDs sequenciais funcionam muito bem… até deixarem de funcionar.

UUIDs resolvem tudo? Mais ou menos

UUIDs (ou GUIDs) são extremamente populares — e com bons motivos.

Eles oferecem:

• Unicidade global
• Geração totalmente descentralizada
• Suporte nativo em praticamente todas as linguagens
• Facilidade para geração no frontend, backend ou offline

Isso os torna uma excelente escolha para:

• Integrações externas
• Sistemas sem controle rígido de infraestrutura
• Sincronizações offline
• Casos onde flexibilidade é mais importante que controle

Mas essa flexibilidade vem com um custo.

UUIDs:

• Não carregam significado operacional
• São ruins para ordenação temporal (especialmente V4)
• Geram índices grandes (128 bits)
• Podem degradar performance em tabelas massivas
• Não ajudam na observabilidade

Em muitos casos, unicidade global não é tudo o que o negócio precisa.

Quando você quer mais controle que o UUID oferece

Agora imagine que você queira:

• Saber quando um registro foi criado apenas olhando o ID
• Garantir ordenação temporal forte
• Evitar gargalo no banco
• Melhorar eficiência de índices
• Facilitar particionamento
• Ter previsibilidade operacional

É nesse ponto que entra o Snowflake ID.

O que é um Snowflake ID?

Snowflake IDs são identificadores numéricos de 64 bits, criados originalmente pelo Twitter por volta de 2010 para identificar tweets em um sistema altamente distribuído.

A ideia central não é apenas gerar um ID único, mas controlar como ele é gerado.

A estrutura clássica do Snowflake é:

• 1 bit: sempre zero (sinal)
• 41 bits: timestamp (baseado em uma época customizada)
• 10 bits: identificador do nó / instância
• 12 bits: sequência local naquele nó

Isso permite:

• Até 4.096 IDs por milissegundo por nó
• Milhões de IDs por segundo em escala horizontal
• Geração totalmente local, sem coordenação central

IDs que já nascem distribuídos

Uma característica fundamental do Snowflake é que:

cada nó é responsável por gerar seus próprios IDs.

Isso elimina:

• Locks globais
• Dependência do banco
• Gargalos de sequência
• Contenção em ambientes paralelos

O banco deixa de ser o “gerador de IDs” e passa a ser apenas um consumidor deles.

IDs que contam uma história

Um efeito colateral (positivo) dessa estrutura é que os Snowflake IDs são temporalmente ordenáveis.

Isso significa que:

• Você pode ordenar registros pelo ID
• Extrair data e hora de criação
• Identificar picos de tráfego
• Analisar padrões operacionais

Tudo isso sem metadados adicionais.

O próprio ID já carrega essas informações.

Por que grandes APIs usam Snowflakes?

Agora fica mais fácil entender por que grandes plataformas adotam esse modelo.

Entre os principais benefícios:

• Menor acoplamento ao banco de dados
• Melhor eficiência de índices (64 bits)
• Ordenação temporal natural
• Excelente suporte a particionamento
• Melhor observabilidade
• Geração previsível e controlada

No Instagram, por exemplo, os bits que representariam o nó físico são usados para identificar shards lógicos.
No Discord, esses bits são divididos entre worker e processo.

Ou seja: o conceito é o mesmo, mas a implementação se adapta à infraestrutura.

Os custos e riscos dessa estratégia

Snowflake IDs não são uma bala de prata.

Eles exigem:

• Configuração correta de infraestrutura
• Garantia absoluta de unicidade do ID do nó
• Disciplina arquitetural
• Sincronização de relógio (clock drift)
• Estratégia clara de deploy e autoscaling

Além disso:

• Snowflake não é um padrão formal
• Não existe uma RFC
• Cada implementação é uma variação

Isso traz flexibilidade, mas também responsabilidade.

Outro ponto importante:
Snowflakes vazam informação temporal.
Se isso for um problema para o seu negócio, essa estratégia pode não ser adequada.

Snowflake vs UUID: um resumo honesto

UUIDs

• Simples
• Amplamente suportados
• Flexíveis
• Ótimos para começar
• Pouco controle
• Pior performance em escala extrema

Snowflake IDs

• Controle explícito
• Excelente para sistemas distribuídos
• Melhores índices
• Ordenação temporal
• Mais complexidade
• Forte dependência da infraestrutura

Não existe “melhor ID universal”.
Existe o ID certo para o seu contexto.

Identificadores são decisão arquitetural

Talvez o ponto mais importante de todo esse artigo seja este:

A escolha do identificador não é detalhe de implementação.

Ela impacta:

• Escalabilidade
• Observabilidade
• Performance
• Segurança
• Evolução do sistema

Escolher entre ID sequencial, UUID ou Snowflake é escolher como seu sistema cresce, opera e se mantém.

E isso é, por definição, uma decisão arquitetural.

Conclusão

Grandes APIs não escolhem Snowflake IDs por moda ou acaso.

Elas escolhem porque:

• Precisam de controle
• Precisam de escala
• Precisam de previsibilidade
• Precisam operar sistemas distribuídos reais

UUIDs continuam sendo excelentes ferramentas.
Snowflakes são ferramentas mais especializadas.

Saber quando usar cada uma é o que separa uma decisão técnica de uma decisão arquitetural.

Se quiser, no próximo artigo a gente pode explorar:

• UUID V7 vs Snowflake
• NanoID, KSUID, ULID
• IDs naturais
• Estratégias híbridas
• Impacto direto em bancos relacionais

Se esse tema te fez repensar a forma como você cria IDs nas suas APIs, comenta lá no blog ou compartilha com o time.
Essa discussão vale muito a pena continuar.

The post Snowflake IDs: por que grandes APIs evitam UUIDs como identificadores públicos appeared first on essencia.dev.