O Que É Número Consecutivo

O que é número consecutivo na prática

Número consecutivo é, tecnicamente, uma sequência de valores numéricos em que cada elemento é exatamente igual ao anterior mais uma unidade. Simples assim. Mas quando você trabalha com geração automática desses números em sistemas reais, a coisa fica bem menos simples do que parece pela definição teórica. Em muitos contextos empresariais, especialmente em emissão de documentos fiscais, numeradores consecutivos aparecem como sequências de identificação de pedidos, notas, protocolos ou regimentos internos. A lógica é sempre a mesma: pegue o último valor gerado e some um.

o que é número consecutivo e como ele funciona nos sistemas

A operação de base é extremamente trivial. Você consulta qual é o último número utilizado, incrementa e salva o novo valor. O problema é que esse processo parece seguro até você encontrar concorrência real no banco de dados. Eu trabalhei em um sistema de emissão de ordens de serviço onde dois funcionários podiam gerar documentos simultaneamente. O cenário era o seguinte: o número 1045 estava marcado como usado. O funcionário A fez a consulta e recebeu 1045 como próximo valor. Quase ao mesmo tempo, o funcionário B fez a mesma consulta e também recebeu 1045. Ambos gravaram. Dois documentos com o mesmo número consecutivo. Isso gerou problema fiscal e precisei resolver em produção dentro de uma hora. A solução que implementamos foi usar uma tabela dedicada de numeração com lock pessimista. Em vez de simplesmente incrementar e confiar, criamos uma thread responsável por reservar blocos de números. Cada thread que precisa de um número vai até essa reserva e o retira de forma atômica. O bloco padrão que definimos tinha 50 números, o que reduziu as consultas ao banco em cerca de 98 por cento em comparação com a abordagem ingênua de ler e incrementar um por um.

Implementação técnica

A estrutura mais comum para guardar esses números é uma tabela pequena com duas colunas principais: o identificador do documento e o último número usado. Você pode adicionar uma coluna de status e outra de controle de concorrência se quiser mais robustez. Exemplo básico de tabela: id INT PRIMARY KEY
ultimo_numero BIGINT NOT NULL
tipo_documento VARCHAR(50) NOT NULL

Para recuperar o próximo número de forma segura, a operação SQL precisa ser atômica. O comando UPDATE comRETURNING no PostgreSQL ou SELECT FOR UPDATE no MySQL funcionam bem: UPDATE numeros_consecutivos SET ultimo_numero = ultimo_numero + 1 WHERE tipo_documento = 'OS' RETURNING ultimo_numero; Esse comando resolve o problema de concorrência que eu descrevi antes porque o banco garante que apenas uma transação consegue executar esse UPDATE por linha ao mesmo tempo. Se duas threads tentarem ao mesmo tempo, uma espera pela liberação da outra. O custo dessa espera é geralmente da ordem de milissegundos em cargas normais.

Se você não tem PostgreSQL disponível, a alternativa com SELECT FOR UPDATE envolve duas etapas: primeiro você trava a linha com uma leitura exclusiva, depois faz o UPDATE. Funciona, mas é mais verboso e propenso a erro se você esquecer o LOCK na primeira etapa.

Pitfalls comuns que iniciantes cometem

O erro mais frequente que eu vejo é tratar número consecutivo como algo que pode ser calculado fora do banco. Alguém sugere usar uma variável de sessão ou um contador em memória. Isso funciona em aplicações singleton rodando em um único processo. Se você escalar para mais de uma instância, como acontece em qualquer ambiente de produção razoável, os números vão se repetir. Já vi sistemas onde dois servidores geravam os mesmos cinco números seguidos antes de perceberem o problema. Outro erro comum é não pré-alocar números. Se você gera um número por requisição e o banco está lento, sua aplicação vai ficar travada esperando pelo SELECT mais o UPDATE. Com a técnica de blocos que mencionei, você reduz drasticamente a frequência de acesso ao banco e melhora a responsividade geral do sistema. Uma terceira armadilha diz respeito à recuperação após falhas. Se você gera um número, a transação quebra antes de gravar o documento e o número fica órfão, você cria um buraco na sequência. Isso geralmente não é problema para documentos internos, mas para notas fiscais eletrônicas, por exemplo, a SEFAZ pode cobrar explicações. A workaround que eu uso é manter uma tabela de números órfãos e verificar antes de gerar um novo se existe algum número reservado que não foi finalizado. Esse check normalmente leva menos de dois milissegundos por operação.

Alternativas quando o padrão não serve

Existem cenários onde número consecutivo puro não é a resposta certa. Se você precisa de uma sequência que nunca se repita mesmo após migração de dados, restauração de backup ou falha completa do servidor, considere usar IDs gerados por esquema distribuído como(Snowflake) ou um gerador centralizado de UUID v7. Eles entregam ordenação temporal com garantia de unicidade sem depender de estado compartilhado no banco. O trade-off é que esses IDs não são sequenciais no sentido convencional. Um documento pode ter o número 847293 e o próximo pode ser 847294 ou 847299, dependendo de quantas operações paralelas estão ocorrendo. Para a maioria dos casos empresariais isso não importa, mas para quem exige sequência estrita sem lacunas, a solução com lock pessimista e blocos ainda é o caminho mais confiável.

Checklist rápido para validar sua implementação

Verifique se a operação de incremento é atômica no banco. Teste com duas transações simultâneas tentando obter o próximo número e confirme que nenhum valor se repete. Monitore o tempo de espera nas filas de lock; se ultrapassar 100 milissegundos médios, considere aumentar o tamanho do bloco de reserva. Mantenha logs de todas as alocações por pelo menos 90 dias, pois auditoria costuma pedir o rastro completo. A parte mais importante, e a que mais esquecem, é testar a recuperação de um documento perdido. Force uma falha na transação durante a geração e observe o que acontece com o número alocado. Se ele some e é perdido para sempre, sua aplicação vai ter buracos silenciosos na sequência que só aparecem meses depois.