Você já se pegou debugando uma API ou fuçando o banco de dados de um projeto novo e se deparou com aqueles IDs gigantes, cheios de letras, números e hífens?
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.
