Em 24 de setembro de 2026, o Japão fez uma grande troca no sistema nacional de tributos. Logo depois, os guichês das repartições da Receita passaram a levar "um tempão" para receber pagamentos em dinheiro e emitir certidões de quitação, e o portal de declaração eletrônica e-Tax teve vários defeitos e paradas de emergência. Quem já mexeu com sistemas distribuídos ou automação de processos entende bem que um sistema gigante e integrado fique instável logo depois da virada. Mas "entender que quebre" e "ter uma saída de emergência decente quando quebra" são problemas bem diferentes.
Imagine que você está com um trâmite urgente e, no guichê, ouve: "O sistema inteiro está instável e ainda não sabemos quando volta. Se for urgente, venha pessoalmente que a gente atende".
A reação normal é: "Então é só ir lá".
Mas pensando um pouco mais, o cenário fica feio.
Quem não consegue resolver pela internet ou pelo caminho de sempre vai parar no guichê. Do outro lado, o sistema está instável e cada atendimento demora mais. Chega mais gente, mas a capacidade de atender cai.
"Venha que a gente atende" não quer dizer "venha que resolve num piscar de olhos".
Então, se o seu prazo ainda tem folga, esperar passa a ser uma decisão bem racional.
E dá vontade de gritar por dentro:
"Aceita no papel de uma vez, sério".
Só que papel não é um banco de dados de backup mágico.
1. O que aconteceu em setembro de 2026
A Receita Nacional do Japão (NTA) trocou o sistema tributário em 24 de setembro de 2026. Sobre o sistema de nova geração, o KSK2, a NTA já vinha apresentando três conceitos de desenvolvimento:
- Passar do trabalho centrado em documentos em papel para um processamento centrado em dados
- Unificar bancos de dados e aplicações que antes eram separados por tipo de tributo
- Trocar os grandes computadores centrais com sistema operacional próprio por sistemas abertos com sistemas operacionais de uso geral
Ou seja, não foi só uma reforma visual das telas. Mudaram ao mesmo tempo a forma de guardar os dados, as fronteiras entre as aplicações e a própria infraestrutura.
No próprio dia da troca, 24 de setembro, a NTA divulgou um aviso sobre "atrasos nos trâmites nos guichês das repartições da Receita". Explicou que o recebimento em dinheiro, a emissão de certidões de quitação e outros serviços levavam um tempo considerável, e que nem pedindo pelo e-Tax a emissão saía na hora. A troca em si foi concluída, mas houve problema no funcionamento dos sistemas necessários ao atendimento presencial.
Na mesma semana de virada também houve falhas no login pelo Mynaportal (o portal de serviços públicos do Japão ligado ao cartão de número pessoal), erro na tela de confirmação de pagamentos por internet banking, suspensão de algumas funções do e-Tax e paradas de emergência para tratar os incidentes. A suspensão de algumas funções do e-Tax foi anunciada como resolvida até 27 de setembro.
Por outro lado, o aviso sobre o atraso nos guichês continuava no ar em 28 de setembro, como informação urgente no site da NTA. A causa raiz detalhada não havia sido divulgada até esse momento.
E um ponto ainda mais importante: não confunda manutenção programada com falha. Nesta troca, já estavam previstas uma parada longa, das 0h de 19 de setembro às 8h30 do dia 24, e outra de dia inteiro em 26 de setembro. Sobre isso se somaram os defeitos pós-virada e a manutenção de emergência.
Por isso é natural ter a sensação de "isso não está parado o tempo todo?", mas ali se misturam paradas planejadas e paradas por falha.
2. Até um sistema sério que lida com dinheiro quebra. Às vezes, é justamente por isso que ele para
"Se é sistema de imposto e de dinheiro, não deveria ser feito para nunca parar?"
Pela intuição, sim.
Mas em sistemas críticos, além da disponibilidade, existe a consistência.
Num processo de pagamento, por exemplo, o mais assustador não é uma tela demorar cinco minutos para abrir.
- Você pagou e consta como inadimplente
- Uma mesma operação é registrada duas vezes
- Uma certidão é emitida com dados desatualizados
- Só um dos sistemas é atualizado e o outro fica para trás
- Ao reexecutar depois da recuperação, a mesma operação roda de novo
Nesse estado, "deixamos rodando mesmo assim" pode ser mais perigoso do que parar.
O material de SRE (engenharia de confiabilidade de sites) do Google também explica que, numa falha grande, convém primeiro conter o dano antes de investigar a causa raiz, e que, se houver risco de corrupção de dados, pode ser melhor congelar o sistema.
Não é que pare apesar de ser coisa de dinheiro.
É que, por ser coisa de dinheiro, às vezes é preciso parar em vez de continuar rodando sem poder garantir um estado correto.
Se "já tentou reiniciar?" resolvesse tudo, o pessoal que cuida dos sistemas centrais do país inteiro sairia bem mais cedo do trabalho.
3. Mesmo com todos os testes unitários passando, ao integrar explode normalmente
O pior dos sistemas integrados é que cada peça pode estar normal e o conjunto, quebrado.
O sistema A está normal.
O sistema B também.
O banco de dados também.
A autenticação também.
Mesmo assim, se o formato passado de A para B diferir em um único caractere, tudo trava.
Se os dados migrados do sistema antigo para o novo tiverem um valor fora do comum, trava.
Se, no meio de uma nova tentativa, só a resposta se perde, ninguém sabe se a operação foi processada ou não.
Cache velho, formulário velho, conexão com órgãos externos, permissões, horários, processamento em lote, codificação de caracteres, ideogramas antigos, reenvios após falha. Quanto mais fronteiras, mais combinações que não apareciam isoladamente.
Até uma pequena automação pessoal dá problema fácil com estado antigo, execução duplicada, itens perdidos, diferenças em APIs externas e efeitos colaterais de novas tentativas.
Agora faça isso num sistema central que abrange as repartições do país inteiro, vários tributos, arrecadação, restituição, certidões, e-Tax e órgãos externos.
Quem sabe como é difícil integrar pensa: "bom, logo depois da virada alguma coisa sempre aparece".
Só que isso não é salvo-conduto.
O que se deve avaliar não é apenas se não houve nenhuma falha, mas até onde se conseguiu reduzir o serviço com segurança quando elas aconteceram.
4. Por que se chega ao "não há previsão de recuperação"
Para o usuário, essa é uma das frases mais irritantes:
"A data de recuperação ainda não foi definida."
Mas prometer um horário qualquer quando a causa ainda é desconhecida pode ser mais perigoso.
Recuperar um sistema crítico não é só ligar o servidor de novo e pronto.
Primeiro, delimita-se o alcance da falha.
Depois, verifica-se se os dados não foram gravados pela metade.
Confere-se se reexecutar não vai gerar processamento duplicado.
Confere-se se o estado não ficou divergente em relação aos sistemas externos conectados.
Se for preciso, avalia-se voltar atrás ou usar um caminho alternativo.
Depois da recuperação, o que se acumulou durante a parada é processado em ordem e os resultados são conferidos.
Fica especialmente complicado quando surge um estado do tipo "do lado de quem enviou parece que deu certo, mas do lado de quem recebeu não foi confirmado".
Num texto sobre projeto de sistemas distribuídos publicado pela Amazon, também se explica que, para tornar as novas tentativas seguras, é fundamental a idempotência: reenviar a mesma requisição sem duplicar os efeitos.
Não dar horário de recuperação não prova que os responsáveis estão de braços cruzados.
Sem saber até onde quebrou, até onde dá para voltar e de onde retomar sem processar duas vezes, é difícil até fazer uma previsão precisa.
5. "Se for urgente, venha ao guichê" é bem assustador como fila de espera
É aqui que o guichê entra em cena.
Mesmo com o sistema fora do ar, às vezes se diz "se vier pessoalmente, a gente atende".
É uma saída de emergência bem-vinda.
Mas, do ponto de vista do tempo de espera, reúnem-se condições perigosas.
Vamos simplificar o funcionamento normal.
Chame de λ a quantidade de pessoas que chegam ao guichê e de μ a quantidade que os servidores conseguem atender.
Quando há uma falha, duas coisas podem acontecer ao mesmo tempo.
Primeiro, até quem normalmente resolveria pela internet ou por processos internos vai ao guichê, e λ sobe.
Segundo, usar o sistema fica mais difícil para os servidores, cada atendimento exige mais conferência e digitação manual, e μ cai.
A demanda sobe e a capacidade de atender cai.
Para uma fila, é a pior combinação.
E os servidores das repartições não se multiplicam sozinhos quando a falha acontece.
O material de SRE do Google também aponta que, ao se aproximar da sobrecarga, o sistema não fica só um pouco mais lento: pode piorar de forma não linear, por causa do aumento das esperas e de falhas em cascata. Por isso são importantes o controle de carga e as respostas com serviço reduzido.
"Se vier ao guichê, a gente atende" não significa "o guichê está vazio".
Se o seu prazo tem folga, não ir no pico da falha e esperar a recuperação é uma decisão bem racional, considerando o custo em tempo.
Por outro lado, se houver prazo legal ou urgência, não deixe para lá por conta própria: confira nos avisos oficiais da NTA ou da repartição, naquele momento, quais são as alternativas.
6. "Faz em papel" é meio certo. O papel serve de saída para o recebimento, mas não é um banco de dados de backup
Olhando essas falhas, vai nascendo um pensamento:
"É só receber no papel, ué."
Essa ideia não é totalmente errada.
O guia de planejamento de continuidade para sistemas de informação do NIST (o instituto de normas dos Estados Unidos) também inclui, como forma alternativa de operar durante uma falha, executar manualmente parte ou a totalidade dos processos de trabalho por um curto período.
Ou seja, o trabalho manual é, sim, uma medida de continuidade legítima.
Mas isso não quer dizer que "escrever no papel resolve tudo".
O que dá para fazer no papel é, por exemplo, isto:
- Registrar o fato de que uma solicitação ou consulta foi recebida
- Fixar a data e a hora do recebimento
- Ficar com os documentos necessários
- Montar uma ordem de processamento para depois da recuperação
- Entregar um número de protocolo ou um comprovante
Já a conferência dos dados centrais, a verificação da situação do pagamento, a consulta a registros antigos, a emissão correta de certidões e a integração com órgãos externos podem não se completar sem o sistema central.
Por isso, o ideal não é "voltar tudo para o papel".
É que, mesmo com o sistema central fora do ar, o recebimento não morra junto.
Papel não é banco de dados de backup.
Mas um comprovante de recebimento em papel pode ser uma saída de emergência.
7. O que realmente se quer é uma "operação reduzida" que não pare por completo
Um sistema resistente a falhas nem sempre mantém 100 % das funções normais.
Ao contrário, ele preserva só as funções importantes e passa para um modo simplificado.
O Google SRE trata isso como degradação gradual de funções, a chamada graceful degradation. O NIST também cita instalações alternativas, locais alternativos e processos manuais como opções de um plano de continuidade.
Aplicado aos trâmites tributários, o cenário ideal seria mais ou menos este:
- Não parar o recebimento. Conseguir receber ao menos as informações básicas da solicitação, off-line ou em papel.
- Emitir um número de protocolo. Acabar com o "não sei se receberam".
- Colocar numa fila de processamento posterior. Poder reprocessar em ordem depois da recuperação.
- Evitar processamento duplicado. Ter um identificador que faça uma mesma solicitação, mesmo reenviada, valer como uma só.
- Separar por urgência. Priorizar o que tem prazo ou grande impacto na vida das pessoas.
- Mostrar o status aos usuários. Informar separadamente o que está parado, o que dá para usar e o que já foi recuperado.
- Conciliar depois da recuperação. Cruzar o que foi recebido em papel ou off-line com os dados de produção, para detectar perdas e duplicidades.
O importante não é a ilusão de que "mesmo com falha, tudo segue igual".
É projetar a forma como se quebra.
8. Então, com que frequência o e-Tax apresenta problemas?
Nos avisos oficiais do e-Tax em 2026, aparecem vários comunicados de incidentes ao longo do ano: em janeiro, atraso na notificação de pagamento concluído; em fevereiro, falhas na integração com o Mynaportal e dificuldade de login; em março, dificuldade de login; em julho, falhas ao usar o Mynaportal; em agosto, indisponibilidade do pagamento direto e de outras funções; e em setembro, várias falhas logo após a troca.
Mas aqui não dá para contar de qualquer jeito.
Não são todas a mesma falha.
Há problemas do próprio e-Tax e também da integração com o Mynaportal, do pagamento, da exibição e de serviços externos. Além disso, manutenção programada não é falha.
Por isso, o que se pode dizer a partir da lista oficial é que "falhas parciais e problemas de integração periférica são anunciados várias vezes por ano", e não que "o sistema tributário inteiro vive parando no país todo".
O caso de setembro de 2026 chama a atenção principalmente porque, na semana de virada de uma troca gigantesca, uma parada planejada longa e várias falhas pós-virada se juntaram.
9. Quem conhece o inferno da integração passa a se irritar de outro jeito
Quem já construiu um pequeno sistema automatizado olha de outro modo para as falhas de grandes sistemas.
Antes, a reação era:
"Como é que uma coisa dessas para?"
E pronto.
Mas depois de conectar vários serviços, usar filas, colocar novas tentativas, guardar estados e integrar com APIs externas, aparece também outra reação:
"Nossa, virada de sistema integrado. Isso é um inferno."
Isoladamente tudo funciona, mas no conjunto quebra.
Você conserta uma coisa e quebra outra fronteira.
Sobra estado antigo.
Tenta de novo e duplica.
Olha o log e era a informação de ontem.
Só de viver uma versão pequena disso já fica mais fácil imaginar como é difícil um sistema central gigante.
Mas entender é diferente de avaliar.
Em vez de encerrar com "é difícil, fazer o quê", vale olhar para o seguinte:
- Até onde foram feitos testes de carga e de migração antes da virada
- Até onde foi possível operar com serviço reduzido durante a falha
- Até onde o recebimento manual funcionou
- Se os avisos de status foram suficientes para os usuários
- Se, depois da recuperação, serão divulgadas a causa e as medidas para evitar repetição
- Se na próxima virada será possível eliminar o mesmo tipo de acidente
Por ser complexo, acidentes podem acontecer.
Justamente por ser complexo, o projeto e o aprendizado depois do acidente são importantes.
10. Conclusão: não é "faz tudo em papel", e sim "nem que seja em papel, não deixe a porta de entrada morrer"
Quando o sistema central de uma repartição da Receita para, aos olhos do usuário parece bem injusto.
É um lugar que lida com dinheiro e trâmites legais, e mesmo assim para.
Nem se sabe quando volta.
Dizem que dá para ir ao guichê, mas é óbvio que vai estar lotado.
Aí dá vontade de dizer "faz em papel de uma vez".
Dentro dessa sensação há uma exigência de projeto bem importante.
Substituir o sistema tributário inteiro só com papel não é realista.
Mas também não é preciso que, no instante em que o sistema cai, morram junto o recebimento, o registro, a priorização e a fila de processamento posterior.
O que um sistema gigante precisa não é o mito de que "nunca vai quebrar".
É que, mesmo quebrando, sobre ao menos o trabalho mínimo.
Que dê para voltar atrás sem processar nada em duplicidade.
Que se informe aos usuários o que funciona e o que não funciona.
E que, depois da recuperação, seja possível recolher com segurança o trabalho que ficou parado.
Em resumo, a exigência final é esta:
Não é "faz tudo em papel".
É "pelo menos o recebimento tem que dar para levantar nem que seja em papel. Sério".
Referências
- Receita Nacional do Japão (NTA), "Sobre os atrasos nos trâmites nos guichês das repartições da Receita", 2026-09-24
https://www.nta.go.jp/files/000041014.pdf - NTA, "Sobre a troca do sistema tributário nacional"
https://www.nta.go.jp/taxes/shiraberu/sodan/system.htm - Relatório da NTA 2025, "Sistema de nova geração (KSK2)"
https://www.nta.go.jp/about/introduction/torikumi/report/2025/03_5.htm - e-Tax, "Sobre o horário de manutenção associado à troca do sistema tributário nacional"
https://www.e-tax.nta.go.jp/topics/2026/topics_20260422.htm - e-Tax, "Lista de avisos"
https://www.e-tax.nta.go.jp/topics/ - e-Tax, "[Resolvido] Sobre a indisponibilidade do e-Tax"
https://www.e-tax.nta.go.jp/topics/2026/topics_20260925_mentenansu.htm - NIST SP 800-34 Rev.1, Contingency Planning Guide for Federal Information Systems
https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final - Google Site Reliability Engineering, Handling Overload / Effective Troubleshooting
https://sre.google/sre-book/handling-overload/
https://sre.google/sre-book/effective-troubleshooting/ - Amazon Builders’ Library, Making retries safe with idempotent APIs
https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/
