Numeração automática em sistemas: a parte que ninguém documenta
Como resolver uma atividade de numeração quando tudo dá errado
Eu já perdi conta de quantas vezes vi alguém tentar montar um sistema de numeração automática e se deparar com duplicatas no meio da execução. O problema não é a lógica em si, é a concorrência. Quando mais de um usuário gera um registro ao mesmo tempo, a sequência simplesmente quebra. Achei que fosse bug do banco, era isso mesmo. Passei duas semanas revisando triggers, queries e até lógica de negócio antes de entender que o problema estava na camada de aplicação. A solução foi mais simples do que eu esperava, mas exige que você pare de tratar numeração como um atributo qualquer. Uma atividade de numeração é basicamente a atribuição automática de um identificador sequencial a um registro, geralmente num formulário ou processo de cadastro. Serve para organizar, rastrear e evitar ambiguidade. Parece trivial até você precisar gerar números em ambiente compartilhado e perceber que duas pessoas podem “puxar” o mesmo número se a trava não estiver no lugar certo. Eu trabalho com sistemas que recebem mais de duzentos cadastros por hora em horários de pico. Se você não tiver um mecanismo de serialização, vai ter conflito.
O formato mais comum é algo como “2024/001”, “PROC-000123” ou “NF-e 35240891234567”. Cada um tem seu contexto. Eu prefiro combinações com prefixo e sequência padronizada porque facilitam a filtragem posterior. Um número só com dígitos funciona bem em tabelas pequenas, mas em sistemas com histórico acumulado ele vira um inferno para auditoria. A regra prática é: se o número precisa ser consultado depois, ele deve carregar contexto. Prefixo, ano, setor. O resto é sequência. Certo dia, num projeto de controle de demandas internas, a equipe pediu numeração automática com base no mês vigente. Criei um trigger que buscava o último número do mês e incrementava. Funcionou até uma segunda-feira de manhã, quando doze pessoas abriram o formulário quase ao mesmo tempo. O banco retornou o mesmo número para três registros. A sequência ficou buracos e duplicatas. Ajustei usando uma fila dedicada com trava row-level, mas o custo de performance foi alto. A solução final foi migrar para um serviço externo de geração de ID com namespace, separado da tabela principal. Ganhamos consistência e perdemos uns quinze minutos na migração dos dados antigos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Se você está construindo algo simples, pode usar uma tabela separada só para reservas de número. Ela armazena o último valor atribuído por grupo e é travada durante a operação. Isso evita que a tabela principal seja acessada multiple vezes em paralelo. O overhead é baixo, mas exige que você trate falhas de conexão com retry, senão o número simplesmente some e o registro fica sem identificador. Eu configurei um timeout de cinco segundos e três tentativas antes de abortar. Em produção, isso caiu de doze conflitos por dia para dois ou três por semana. Um erro comum é achar que a numeração sequencial garante ordem cronológica. Ela não garante. Sequência é atribuição, não data. Se você precisa associar a um período, use uma regra explícita: prefixo com ano/mês e sequência independente por período. Aí você evita a tragédia de ter que renumerar tudo porque alguém apagou um registro do meio do lote. Isso acontece. Já vi gente apagar registro “só pra testar” e quebrar a sequência inteira.
Outro ponto que poucos destacam: número sequencial não substitui UUID quando você precisa de portabilidade entre ambientes. Se o sistema vai ter cópias de desenvolvimento, homologação e produção, ou se os registros precisam migrar entre bases, um ID autoincremental local vira pesadelo. Aí entra a escolha entre usar UUIDs para identificação única e manter numeração sequencial apenas para exibição. São coisas diferentes. Não confunda. O primeiro é para o sistema. O segundo é para o usuário. Se o seu cenário envolve alta concorrência, muitos cadastros simultâneos ou necessidade de rastreabilidade por período, a abordagem de fila com trava e namespace externo é mais segura. Se o volume é baixo e o uso é interno, uma simple row-level lock com retry resolve. A escolha depende do nível de risco que você aceita. Eu nunca aconselho depender de trigger sozinho para numeração crítica. Trigger é bom para auditoria, ruim para geração de identidade em ambiente distribuído.
Em resumo, pratique a definição correta desde o início, use prefixos quando houver necessidade de consulta, e nunca conte com sequência pura para identificação em cenários concurrentes. O sistema vai te cobrar isso com conflito, buraco ou duplicata. A correção é mais cara do que a prevenção. E lembre-se: numeração é um recurso, não um acidente. Se ela não está planejada, ela vai Doer.
