Por que autoincremento pode atrapalhar mais do que parece

Quando a identidade só existe depois de passar por um ponto central, o sistema ganha dependência; quando ela nasce independente desde o início, a coordenação deixa de ser um gargalo.

A faculdade nem sempre te prepara para detalhes específicos que aparecem quando você começa a trabalhar com sistemas em produção. Um desses detalhes, pra mim, foi a forma como lidamos com IDs em banco de dados. Nas aulas, o padrão quase sempre era usar autoincremento; e fazia sentido, já que é simples, resolve a chave primária e evita discussões mais profundas no começo.

Mas quando comecei a trabalhar com sistemas reais, percebi que, ao usar autoincremento, eu frequentemente acabava lidando com dois modelos diferentes: um sem ID (antes de persistir) e outro com ID (após o INSERT com RETURNING). Com o tempo, isso criava uma certa redundância e deixava o fluxo menos natural, como se o modelo só ficasse completo depois de salvo no banco.

Depois de um tempo, passei a usar UUID com mais frequência e isso acabou mudando minha forma de pensar o problema. Com UUID, eu consigo criar o modelo já completo desde o início, gerando o identificador na aplicação (por exemplo com crypto.randomUUID), o que elimina a dependência do banco para identidade e melhora a ergonomia do código. Além disso, funciona muito bem em cenários distribuídos (microservices, filas e eventos), reduz acoplamento com o banco na camada de domínio e facilita a criação de dados em ambientes concorrentes.

Mas isso não significa necessariamente que o autoincremento perdeu o valor, pois ele ainda faz bastante sentido em vários cenários: é mais eficiente em armazenamento e indexação, facilita leitura humana em debugging e logs, mantém a ordenação natural de inserção e é amplamente suportado e otimizado em bancos relacionais.

No fim, o que ficou pra mim não foi uma solução final, mas uma mudança de perspectiva: o ID deixou de ser só um detalhe técnico do banco e passou a ser uma decisão de modelagem sobre como o sistema se comporta antes mesmo de chegar nele, considerando o contexto, a arquitetura e até o tipo de dor que se quer evitar.

Não sei se tive aula com os professores errados, mas hoje eu não confiaria só na faculdade para sustentar o que a gente precisa no dia a dia de trabalho. O conhecimento muda, as práticas mudam, e o que parecia padrão em sala de aula pode não se sustentar tão bem em produção. No fim, o jeito de lidar com IDs foi só mais um lembrete de como a gente vai ajustando a forma de pensar conforme criamos as coisas na prática.