Você tem um ponto — mas vale olhar o cenário completo: IDs como UUID, ULID e... · kaioodutra

Você tem um ponto — mas vale olhar o cenário completo:

IDs como UUID, ULID e Snowflake não foram inventados para complicar, mas sim para resolver problemas reais: escalabilidade, distribuição, exposição pública de dados, rastreabilidade e segurança passiva.

Se você tem um sistema local, centralizado, como uma padaria ou ERP interno, usar AUTO_INCREMENT (1, 2, 3...) faz total sentido. É simples, direto, performático, e o próprio banco garante integridade.

Mas se você pensa em crescer...

Quando seu sistema começa a se expandir — seja com APIs públicas, microsserviços, recursos abertos como rastreios e compartilhamentos — a previsibilidade dos IDs se torna um vetor real de exploração.

Mesmo sem vazar dados sensíveis diretamente, um atacante pode:

Mapear /pedido/1, /pedido/2, /pedido/3... por brute force;
Descobrir quantos registros existem no sistema;
Levantar padrões internos (quem compra mais, horários, status etc.);
Fazer scraping contínuo de dados públicos;
Criar até serviços paralelos não autorizados, sem usar sua API, apenas explorando a previsibilidade do padrão de URL.

E isso tudo sem quebrar sua segurança — só explorando sua arquitetura.

IDs aleatórios mitigam esse risco

Usar ULID, UUIDv7 ou até hash público ajuda a:

Evitar enumeração simples (não dá pra saber o "próximo");
Forçar uso da API oficial, com autenticação e limites;
Desacoplar lógica interna do acesso externo;
Reduzir a superfície de scraping automatizado.

E o argumento do "espaço"?

O custo de armazenamento de UUIDs ou ULIDs é irrelevante para 99% dos sistemas modernos. Se seu sistema não roda com dezenas de milhões de requisições por minuto, isso nem deveria ser uma preocupação.

Conclusão prática

AUTO_INCREMENT é perfeito para sistemas internos, fechados e simples.
IDs aleatórios fazem mais sentido quando:
- o sistema está exposto ao público;
- há risco de scraping ou indexação não autorizada;
- a arquitetura envolve microsserviços e alta escala;
- você quer desacoplar o ID do comportamento interno.

Um ID previsível pode virar um endpoint público involuntário.
E nesse momento, o controle do seu sistema já não é mais só seu.

Já está respondido no meu comentário anterior, isso é quase um hoax que se espalhou. Claro que tem algum mérito no que disse, mas a maior parte disso é algo que só se vivencia quando o sistema é todo errado, é uma rolha para tapar um buraco na represa, conserta o buraco.

Eu poderia citar diversos sistemas dos mais conhecidos que não fazem isso e estão bem. Inclusive, apesar da distribuição necessária porque é um dos 5 sites de maior tráfego do mundo, precisam de bem menos servidores doque as pessoas imaginam, mais por causa do espaço do que pelo processamento, usam um sistema sequencial (repito, mesmo distribuído), previsível e não tem problema de segurança, além de ter apenas 8 bytes (já que recebem perto de bilhão de novas informações por dia). Mas lá tem engenheiros de verdade, não que aprenderam por receita de bolo. Tem muitos casos. E eles fizeram isso porque o custo geral do uso de um ID em PK de 16 bytes era proibitivo, com dados que comprovavam isso, não especulação. Nem vou entrar no mérito que quase toda distribuição feita é desnecessária. Tem exemplo de site que já foi dos 30 mais acessados do mundo que não tinha.

Existe uma diferença quando o ID é usado para outra coisa que não seja controle do banco de dados, esse é outro assunto completamente diferente e por não ser PK não é tem o mesmo tipo de problema.