Arquitetura Event-Driven para Conciliação Pix: Kafka, SNS ou RabbitMQ?

O Banco Central registrou 224 milhões de transações via Pix em um único dia em abril de 2024. Se você opera um gateway de pagamentos, uma subadquirente ou um banco digital, sabe exatamente o que esse número significa. Significa servidores suando frio. Significa bancos de dados relacionais implorando por clemência devido a deadlocks. Significa que processar webhooks de forma síncrona não é apenas amadorismo — é suicídio financeiro.

Nossa análise técnica na Ouro Capital, conversando com dezenas de CTOs e arquitetos de software do mercado financeiro paulista, aponta uma realidade inegável. A era das integrações ponto a ponto via APIs RESTful para conciliação de pagamentos acabou. O Pix forçou o mercado a amadurecer dez anos em três.

A arquitetura orientada a eventos (event-driven architecture - EDA) deixou de ser um preciosismo de engenharia do Nubank ou do Mercado Pago para se tornar o padrão de sobrevivência de qualquer fintech de esquina. Mas quando o volume baté na porta, a prateleira de soluções de mensageria oferece três caminhos principais: Apache Kafka, RabbitMQ e a dupla gerenciada da AWS (SNS/SQS).

Qual deles aguenta o tranco do Sistema de Pagamentos Instantâneos (SPI) sem quebrar a ordem das transações ou estourar a conta da nuvem?

O Fim da Era Síncrona no Pix

Antes de dissecarmos as ferramentas, precisamos alinhar a física do problema. O Manual de Fluxos do Pix e a Resolução BCB nº 1 não dão margem para brincadeiras. O SLA do Banco Central exige que 99% das transações sejam liquidadas em até 10 segundos.

Na prática, o seu Participante Direto (PSP) precisa processar a mensagem pacs.008 (liquidação), atualizar o saldo do recebedor, disparar o webhook para o e-commerce e confirmar a operação em questão de milissegundos. Se você faz isso de forma síncrona, um simples timeout no servidor do e-commerce do seu cliente prende a thread da sua aplicação. Multiplique isso por 5.000 transações por segundo (TPS) numa Black Friday. O resultado? Seu pool de conexões esgota, o gateway cai e o COAF ou o BACEN começam a fazer perguntas desconfortáveis sobre a sua resiliência operacional.

A solução óbvia é desacoplar. O gateway recebe o callback do SPI, joga a mensagem em um broker de eventos, devolve um HTTP 200 pro BACEN na velocidade da luz e deixa os workers internos processarem a conciliação e os webhooks no próprio ritmo.

O diabo, como sempre, mora nos detalhes da implementação dessa fila.

Apache Kafka: O Canhão de Milhões de TPS

Vamos começar pelo peso-pesado. Criado no LinkedIn e adotado por gigantes como Itaú e Nubank, o Apache Kafka não é uma fila de mensagens tradicional. Ele é um log de eventos distribuído, persistente e imutável.

Se você processa mais de 1.000 transações por segundo e precisa de retenção histórica, o Kafka engole esse volume sem pestanejar. A grande vantagem estrutural aqui para a conciliação do Pix é a capacidade de "replay".

Imagine que um deploy desastroso na sexta-feira à noite corrompeu a lógica de atualização de saldo na sua base de dados. Com RabbitMQ ou SQS padrão, uma vez que a mensagem foi consumida e o ack (acknowledgment) foi enviado, a mensagem some. Com o Kafka, o evento continua lá no disco. Basta voltar o offset do seu consumer group para sexta-feira às 18h e reprocessar todos os eventos do Pix do fim de semana corretamente.

O Desafio da Ordenação (Partition Key)

No mundo do Pix, a ordem importa. Você não pode processar uma notificação de devolução (pacs.004) antes de ter processado a liquidação original (pacs.008). O Kafka resolve isso com partições. Se você usar o EndToEndId (o identificador único transacional do Pix) como Partition Key, o Kafka garante matemáticamente que todos os eventos daquela transação específica cairão na mesma partição e serão lidos em ordem cronológica estrita.

A pegadinha? O Kafka exige uma equipe de infraestrutura de elite. Gerenciar clusters, lidar com o ZooKeeper (ou o novo KRaft), balancear partições e monitorar discos cheios não é tarefa para juniores. O custo operacional em engenharia é brutal.

RabbitMQ: O Cirurgião do Roteamento

Se o Kafka é um trem de carga em alta velocidade, o RabbitMQ é o centro de triagem dos Correios. Baseado no protocolo AMQP, ele brilha quando a complexidade das regras de negócio supera o volume bruto de dados.

Observamos muitos gateways de médio porte e subadquirentes adotando o RabbitMQ pela sua flexibilidade de roteamento (Exchanges). Você pode configurar um Topic Exchange onde a chave de roteamento é algo como pix.recebimento.cliente_xpto.

Isso permite uma arquitetura elegante: um microserviço escuta apenas os recebimentos, outro escuta apenas as devoluções, e um terceiro escuta eventos específicos de clientes VIP que pagam por SLAs menores.

O Calcanhar de Aquiles: Memória e Retenção

O RabbitMQ foi feito para esvaziar filas. Mensagens acumuladas são um antipadrão aqui. Se o seu banco de dados cai e os workers param de consumir as mensagens do Pix, a fila começa a crescer. O RabbitMQ armazena mensagens em memória (mesmo as persistentes usam RAM para índices). Quando o limite de memória é atingido, ele bloqueia públicadores. Seu gateway para de aceitar novos Pix.

Para operações de conciliação que precisam lidar com picos sazonais absurdos (como o quinto dia útil do mês) sem provisionar infraestrutura gigantesca ociosa no resto do mês, o RabbitMQ exige um tuning fino de Dead Letter Exchanges (DLX) e políticas de TTL (Time to Live) para não derrubar a operação.

AWS SNS e SQS: O Caminho de Menor Resistência

Para a esmagadora maioria das fintechs em estágio inicial ou intermediário, gerenciar infraestrutura de mensageria é desperdício de venture capital. A AWS oferece o Simple Notification Service (SNS) acoplado ao Simple Queue Service (SQS).

A arquitetura clássica é simples: o webhook do Pix baté no API Gateway, aciona um Lambda ou um microserviço no ECS/EKS, que pública no SNS. O SNS faz o fan-out (distribui) para várias filas SQS. Uma fila atualiza o ledger, outra manda o webhook pro cliente, outra consolida dados pro time de fraude.

Stone, Pagar.me e dezenas de outros players usam o ecossistema da AWS extensivamente. A vantagem é óbvia: zero servidores para gerenciar, escalabilidade práticamente infinita e resiliência out-of-the-box.

O Preço da Conveniência e o Limite do FIFO

Lembra da exigência de ordenação das mensagens do Pix? O SQS padrão não garante ordem. A mensagem B pode chegar antes da A. Para resolver isso, você precisa usar o SQS FIFO (First-In-First-Out).

Aqui a AWS cobra o seu pedágio. O SQS FIFO tem um limite rígido de throughput. Usando batching (agrupamento de mensagens), o limite máximo é de 3.000 mensagens por segundo por chamada de API. Se a sua processadora começar a bater 5.000, 10.000 TPS, o SQS FIFO vira o gargalo da sua operação.

Além disso, o custo escala linearmente. Pagar por milhão de requests no SQS parece barato no início (US$ 0,40 a US$ 0,50 por milhão). Mas quando você processa 50 milhões de transações diárias, com 4 filas diferentes lendo cada evento, a fatura no fim do mês engole a sua margem de lucro por transação.

Idempotência: O Escudo Definitivo

Independentemente de escolher Kafka, RabbitMQ ou SQS, existe uma regra de ouro na arquitetura event-driven para pagamentos: a garantia de entrega de todos esses sistemas é "At Least Once" (pelo menos uma vez).

Isso significa que, em caso de falhas de rede, o broker vai entregar a mesma notificação de Pix duas vezes para o seu worker. Se o seu sistema não for idempotente, você vai creditar R$ 100 duas vezes na conta do recebedor.

Na nossa análise das melhores práticas do mercado brasileiro, a chave de idempotência definitiva é o EndToEndId cruzado com o TxId. O banco de dados relacional (geralmente PostgreSQL) deve ter uma constraint de unicidade (Unique Index) nesses campos. Quando a mensagem duplicada chega, o banco rejeita a inserção, o worker captura a exceção de duplicidade e dá o ack na fila, ignorando o evento fantasma.

A Preparação para o Pix Automático

Agora em 2024 e olhando para a entrada do Pix Automático em 2025, o volume transacional vai sofrer outra mutação. Estamos falando da migração massiva de débitos em conta, assinaturas de streaming, academias e contas de consumo para os trilhos do Pix.

Isso introduz um novo padrão de tráfego: os picos programados. Milhões de cobranças agendadas para as 00h01 do dia 05 de cada mês. Essa avalanche de eventos simultâneos vai destruir arquiteturas síncronas e filas SQS mal configuradas.

O Veredito Prático para o seu Gateway

A escolha da stack depende inteiramente da sua fase de maturidade e do tamanho do seu balanço patrimonial.

Se você processa até 500 TPS e roda na AWS: vá de SNS/SQS. O tempo de engenharia salvo não tem preço. Implemente SQS FIFO usando o EndToEndId como MessageGroupId para garantir a ordem, ou use SQS Standard com uma lógica robusta de idempotência e ordenação no banco de dados.

Se você tem regras complexas de roteamento, multitenancy agudo (vários sub-clientes com regras diferentes) e um time de operações enxuto: RabbitMQ entrega um meio-termo excelente entre controle e fácilidade de uso.

Se você é uma instituição de pagamento autorizada pelo BACEN, processa milhares de TPS constantes, precisa auditar o log de eventos para compliance e tem um time de engenharia sênior: Apache Kafka não é uma opção, é um requisito. O log persistente do Kafka será o seu melhor amigo quando uma auditoria do Banco Central exigir a reconstrução da linha do tempo de uma liquidação que ocorreu há três meses.

O mercado financeiro não perdoa latência e pune severamente a inconsistência de dados. Construa suas fundações de mensageria não para o volume que você tem hoje, mas para o volume que o Banco Central vai jogar no seu colo nos próximos dois anos.