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.