Um processo obrigatório de comunicação de dados ao governo acumulou mais de 180 dias de atraso, com inconsistências entre Kafka e MongoDB e sem evidências de envio, virando um risco jurídico e regulatório. A Eficify definiu uma fonte de verdade, reconciliou as fontes e reprocessou mais de 10TB de dados inconsistentes com um pipeline distribuído e idempotente, implantando trilhas de auditoria e transformando o compliance em característica da arquitetura.
Contexto
A empresa operava um processo obrigatório de comunicação de dados ao governo sobre uma arquitetura distribuída: múltiplos serviços, filas em Kafka, persistência em MongoDB e várias etapas de transformação e envio.
Com o tempo, falhas acumuladas, ausência de rastreabilidade e inconsistências entre as fontes geraram um atraso superior a 180 dias na transmissão das informações.
O problema
Sem uma visão central do estado de cada registro, em alguns casos o Kafka indicava consumo mas o dado não estava correto no MongoDB; em outros, o dado existia mas não havia evidência de envio ou aceite.
Somavam-se mensagens duplicadas, eventos fora de ordem, falhas silenciosas e versões diferentes do mesmo dado, tornando impossível afirmar com precisão o que havia sido processado, enviado, rejeitado ou estava preso nas filas.
Riscos para o negócio
- Penalidades e questionamentos por descumprimento de prazos regulatórios.
- Impossibilidade de comprovar, em auditoria, o que foi comunicado.
- Dados duplicados ou inconsistentes gerando efeitos regulatórios indevidos.
- Reincidência do passivo por falhas estruturais não corrigidas.
- Risco jurídico e operacional além do problema técnico.
Arquitetura anterior
- Eventos em tópicos Kafka consumidos por múltiplos componentes, sem visão central de estado.
- Persistência em MongoDB divergente do que o Kafka indicava como consumido.
- Mensagens duplicadas, fora de ordem e falhas silenciosas.
- Ausência de evidência de envio e aceite pelo órgão.
- Sem reconciliação, idempotência ou trilha de auditoria por registro.
Diagnóstico da Eficify
Mapeamos todo o fluxo, da geração do evento à resposta do governo, analisando tópicos, partições, offsets, consumidores, coleções, índices, logs, arquivos gerados e históricos de retorno, para identificar onde os registros paravam ou perdiam consistência.
Definimos uma fonte de verdade, com regras de precedência e reconciliação, e transformamos o passivo, antes desconhecido, em um inventário técnico mensurável, classificado por situação (enviado, sem evidência, sem aceite, rejeitado, ausente, duplicado, incompleto ou elegível para reprocessamento).
Solução implementada
Rotinas de reconciliação cruzaram chave de negócio, identificadores técnicos, timestamps, versões, offsets, status, conteúdo do payload e retorno do órgão, usando hashes e assinaturas de conteúdo para diferenciar registros aparentemente iguais e localizar mensagens perdidas, documentos órfãos, duplicidades e divergências de versão.
Estruturamos um pipeline de reprocessamento distribuído, segmentado por período, tipo, situação e criticidade. Workers independentes processavam em paralelo respeitando throughput, dependências e restrições do sistema governamental, com particionamento por chave de negócio (preservando a ordem dos eventos da mesma entidade), controle de concorrência, limitação de taxa, checkpoints, dead-letter queues e retries com backoff.
Como reenviar um dado regulatório não pode gerar efeitos duplicados, todo o fluxo recebeu controles de idempotência: cada operação teve uma chave única e, antes de cada envio, o sistema verificava se o registro já havia sido transmitido, aceito ou estava em processamento. Cada registro passou por validações técnicas e de negócio; os válidos seguiam para reprocessamento e os inconsistentes iam para filas específicas, com o motivo da falha.
Para o compliance jurídico, implantamos uma trilha de auditoria por registro (origem, criação, versão, transformações, tentativas, erros, correções, conteúdo e data do envio, resposta e situação final) e correções estruturais para impedir um novo passivo: versionamento de schemas, contratos entre produtores e consumidores, validação de payloads, reconciliação automática, persistência das confirmações, monitoramento de lag e alertas por prazo regulatório.
Desafios técnicos
- Reconstruir o estado real de cada registro em um fluxo distribuído sem visão central.
- Reprocessar grande volume com idempotência, sem gerar efeitos duplicados.
- Preservar a ordem dos eventos da mesma entidade durante o paralelismo.
- Traduzir exigências jurídicas/regulatórias em controles técnicos verificáveis.
- Impedir a reincidência do passivo com correções estruturais.
Resultados mensuráveis
10TB+De dados inconsistentes reconciliados e reprocessados
180+ diasDe passivo regulatório recuperado de forma controlada
Fonte de verdadeEstado de cada registro determinado e confiável
IdempotênciaReprocessamento sem duplicar efeitos regulatórios
Trilha de auditoriaEvidência ponta a ponta por registro
Sem reincidênciaCorreções estruturais contra novo passivo
“Saímos de um risco regulatório real para uma operação em que sabemos, com evidência, o que foi enviado, aceito ou reprocessado. O compliance virou parte da arquitetura.”