Kafka em Sistemas de Seguros: Arquitetura para Alta Concorrência

Quando uma seguradora precisa processar um alto volume de transações diárias — adesões, pagamentos em débito automático, validações contra listas de risco, tokenização de cartões —, o modelo síncrono de requisição e resposta torna-se frágil se uma operação crítica depende de várias integrações com latências distintas; em picos, esse acoplamento amplifica os tempos de espera quando não há limites e degradação controlada.

O problema real: acoplamento temporal

Em um sistema síncrono tradicional, o tempo que o serviço de tokenização de cartões leva soma-se ao tempo total de resposta da transação. Se a validação contra listas internas de risco, listas de pessoas bloqueadas e fontes de sanções —cada uma com a própria frequência de atualização, versão consultada e evidência— está sob carga, toda a cadeia espera. O resultado é previsível: timeouts, novas tentativas manuais e erros de conciliação.

O Apache Kafka resolve isso com um modelo fundamentalmente diferente: em vez de os serviços chamarem uns aos outros, eles publicam eventos em tópicos (topics) e cada consumidor os processa de forma independente, em ritmo próprio. O Kafka pode oferecer processamento exactly-once dentro de fluxos Kafka bem configurados; quando intervêm APIs, processadores de pagamento ou bancos de dados externos, continuam sendo necessários identificadores idempotentes, tratamento de duplicidades e conciliação (por exemplo, com o padrão outbox).

Como a adesão é resolvida com eventos

O padrão habitual em plataformas de seguros é o seguinte: o início da adesão é publicado como evento, e as validações —identidade, listas restritivas, tokenização do meio de pagamento— são processadas como consumidores independentes que publicam o resultado. A coordenação segue o padrão saga, por coreografia (cada serviço reage aos eventos dos demais) ou por orquestração (um componente reúne os resultados e decide se a adesão prossegue). O valor não está na mensageria, está em que as validações não bloqueiem umas às outras.

A adesão é modelada como uma máquina de estados —pendente, em validação, aprovada, rejeitada, vencida, em revisão— e define-se o que acontece diante de resultados duplicados ou tardios, indisponibilidade de um terceiro e vencimentos.

A diferença operacional é de natureza, não de grau. Um pico de demanda deixa de se converter de imediato em timeouts: a fila absorve o volume e cada consumidor processa no próprio ritmo. Paga-se com latência de processamento. O desacoplamento reduz a propagação de falhas, mas não elimina o risco: são necessários limites de consumo, novas tentativas limitadas, filas de exceção e monitoramento do atraso.

Rastreabilidade como requisito de primeira ordem

Um dos requisitos mais rigorosos no setor segurador é a auditoria. Cada transação — da solicitação inicial à confirmação do pagamento — deve ser rastreável, com timestamps, estados intermediários e identidade do sistema que processou cada etapa. Os eventos são uma fonte valiosa de evidência, mas não substituem uma trilha de auditoria: é preciso definir eventos auditáveis, correlação, carimbo de tempo, integridade, retenção e um repositório consultável separado da retenção do Kafka.

Os tópicos não devem distribuir dados sensíveis: publicam-se referências ou identificadores pseudonimizados e o mínimo de dado necessário; criptografia em trânsito e em repouso, acesso por tópico e retenção definida. Os dados de cartão ficam fora da plataforma de eventos, sob o modelo de responsabilidade do PCI DSS; o que trafega é o token.

Considerações para produção

O Kafka não é gratuito em complexidade operacional. É preciso definir corretamente o número de partições (afeta o paralelismo máximo), o fator de replicação (afeta a durabilidade), a retenção de mensagens (afeta o custo de armazenamento) e as políticas de idempotência dos consumidores (afeta a consistência). Em ambientes Kubernetes, um operador dedicado simplifica consideravelmente o ciclo de vida do cluster.

A regra prática que se confirma no uso é: o Kafka é a escolha correta quando há vários consumidores independentes que precisam do mesmo evento, quando é necessário replay de eventos para depuração ou migração, e quando a disponibilidade do produtor não pode depender da disponibilidade do consumidor. Para comunicação de requisição e resposta entre dois serviços que precisam de resposta imediata, um REST síncrono continua sendo mais simples e adequado.