O elo mais fraco de qualquer stack de faturamento não costuma ser o banco de dados ou a infraestrutura de nuvem, mas as APIs externas — especificamente as governamentais. Diferente de um serviço como AWS ou Stripe, que oferecem SLAs de 99,9%, as APIs de prefeituras e órgãos tributários operam sob instabilidades crônicas, janelas de manutenção não programadas e mudanças de contrato sem aviso prévio.
Se a sua arquitetura não foi desenhada para absorver essa falha, você está herdando a instabilidade de terceiros para dentro do seu produto.
O problema do acoplamento temporal
O erro mais comum é a chamada síncrona: o usuário clica em “Assinar”, e seu servidor tenta emitir a nota fiscal em tempo real para retornar o PDF na tela.
Se a prefeitura demora 15 segundos para responder (ou não responde), sua thread de execução fica presa. Se 100 usuários fizerem isso simultaneamente, seu pool de conexões esgota e seu sistema cai. Isso é o acoplamento temporal. A saúde do seu sistema passa a depender da saúde do servidor do governo.
Implementando um middleware de resiliência
Para escalar, você precisa de uma camada que atue como um “amortecedor” (buffer). Aqui estão os padrões indispensáveis para essa arquitetura:
A. Backoff Exponencial e Retries Inteligentes
Tentar reenviar uma nota imediatamente após um erro 500 é a receita para o desastre. O sistema deve implementar uma estratégia de retentativas com intervalos crescentes (ex: 1min, 5min, 15min, 1h). Isso dá tempo para o serviço externo se estabilizar e evita que sua própria infraestrutura seja bloqueada por excesso de requisições (rate limiting).
B. Idempotência: A barreira contra a duplicidade
Em sistemas distribuídos, o “timeout” é a pior falha, porque você não sabe se a requisição chegou ao destino e caiu na volta, ou se nunca chegou. Sem um ID de Idempotência, o reenvio pode gerar uma nota duplicada. Uma infraestrutura robusta garante que, para cada transação única no seu sistema, apenas um documento fiscal seja autorizado, independentemente de quantas tentativas de rede ocorram.
C. Circuit Breaker (Disjuntor)
Se o monitoramento detecta que a prefeitura de uma cidade específica está offline, o sistema deve “abrir o circuito”. As requisições para aquela cidade param de ser tentadas e entram em uma fila de espera. Isso preserva os recursos do seu sistema e permite que o time de operações saiba exatamente onde está o gargalo, sem gerar milhares de logs de erro inúteis.
Da reação para a observabilidade operacional
Um sistema resiliente transforma “erros técnicos” em “status operacionais”. Em vez de um log de erro 502 nebuloso, sua stack deve fornecer rastreabilidade: “Transação recebida; aguardando janela de processamento da prefeitura X”.
Isso dá autonomia ao time de suporte e financeiro. Eles deixam de abrir chamados para a engenharia porque agora conseguem enxergar o ciclo de vida do documento e saber que o sistema está gerenciando a falha automaticamente.
Conclusão: construa para a falha
O objetivo de uma infraestrutura tributária moderna não é apenas emitir o documento quando tudo vai bem, mas garantir que a empresa continue faturando quando tudo vai mal. Ao isolar essas falhas em uma camada especializada, você remove o risco sistêmico e garante que sua engenharia foque em construir valor, não em debugar instabilidades alheias.
