Filas de mensagens: Kafka e RabbitMQ

Filas de mensagens: Kafka, RabbitMQ

(Secção Tecnologia e Infraestrutura)

Resumo curto

• Apache Kafka é um registro de eventos distribuído, focado em streaming, replicação e skailing horizontal através de partituras.
• RabbitMQ - Corretor de filas AMQP com rotação flexível (exchanges/bindings), prioridades, TTL, confirmações e tarefas clássicas de fila.

As duas ferramentas são maduras, mas resolvem tarefas diferentes: Kafka, para striptease e analistas escaláveis; RabbitMQ, para orquestração operacional de tarefas, RPC e rotação variada.

Onde o que é apropriado em iGaming

• Você precisa de eventos TPS altos (apostas, eventos de jogos, telemetria) e skale horizontal através de partituras.
• Importante é ré-consum frio/quente (ler novamente os dados de fita), retino e compacto para as unidades (equilíbrio, condição do jogador).
• São necessários processos de strim (Kafka Streams/ksqlDB/Flink) para equipamentos realtime - líderes de torneios, limites de jogo responsável, sinais antifrod.

• Você precisa de filas de tarefas clássicas: verificação KYC, pagamentos atrasados/repetidos, envio de e-mail/SMS/push, webhooks para PSP.
• Rotação flexível (topic/direto/fanout), prioridades, TTL, delay, dead-letter e pattern RPC.
• Exigem restrições severas per-consumer (prefetch/QoS), simples gerenciamento de carga e retratos rápidos.

Resultado frequente: Kafka para eventos e analistas + RabbitMQ para orquestração e integração.

Modelo de dados e rotação

Kafka

Os topics dividem-se em partituras, cada um é um logo ordenado.
A chave de mensagem identifica a partilha → a ordem dentro da chave.
Os consoadores são lidos por offset e os grupos de consoadores escalam o processamento.
Retensschn em tempo/volume; A última versão da chave está armazenada.

RabbitMQ

Exchanges (direto/fanout/topic/headers) + bindings → mensagens entram em queues.
Confirmações (ack/nack/requeue), publisher conferms, priorities, TTL, dead-letter (DLX/DLQ).
Quorum queues (Raft) para alta disponibilidade; lazy queues para economizar RAM.

Garantias de entrega e idimpotência

At-matt-once: sem retais; Risco de perdas, atraso mínimo.
At-least-once: padrão padrão → pode duplicar → hendlers idumpotentes (chave de consulta/transação, upsert, tabela de dedup, outbox).
Exactly-once: Em Kafka, é alcançado em conexão de vendedor idumpotente + topics de transação + consumo alinhado, mas mais caro e mais complexo; no RabbitMQ, restrito e com ossos. Os fluxos de pagamento/aposta real aplicam at-least-once + idempotação rigorosa.

• Idempotency-keys (UUID/ULID) exclusivos para o evento/comando.
• Outbox-pattern no BD do serviço + Mudança Data Capture (Debezium) → evitar «gravação dupla».
• Dedup por (key, created _ at) em um estore separado com TTL.

Encomenda/Ordem das mensagens

Kafka garante a ordem dentro da partição. Selecione a chave para que a «vida» da entidade (por exemplo, «player _ id» para o balanço) esteja em uma única chave.
A ordem não está estritamente garantida nas entregas de novo/múltiplos consórcios; pipline crítica à ordem - melhor em Kafka ou através do single-ativo consumer e seriado de fluxo.

Projetar topics e filas

• Granularidade: 'domain. event '(por exemplo,' payments. deposit. created`).
• As chaves são 'player _ id', 'score _ id', 'bet _ id' para ordenar.
• Partições = N pelo TPS de destino (regra: 1 partição ≈ X mensagens/segundos/consumer); empenhar o estoque no crescimento.
• Retenschn: eventos - relógios/dias; compacto para «estados».

• Exchanges por domínios: 'payments. direct`, `risk. topic`.
• As filas para os consumidores são 'kyc. checker. q`, `psp. webhooks. retry. q`.
• DLQ para cada fila de trabalho; delay para backoff.
• Prefetch especifica o paralelismo, as filas de quorum são para HA.

Erros, retraias e DLQ

Classifique os erros como temporários (rede/PSP 5xx) → retraí; fatais (validação, esquema) → imediatamente DLQ.
Exponential backoff + jitter, limite de retais, detecção "poison-pill'.
Retry-queues individuais por passo (5s, 1m, 5m, 1h).
Processador DLQ: alert, trade, anistia manual, injecção com patch.

Contrato de dados e esquema

Use o Avro/Protobuf + Schema Registry (para Kafka - padrão de facto).
Versioning: alterações backward-compatível (adição de campos opcionais), proibição de migração de quebra.
Campos PII - criptografia/toquenização; cumpra o GDPR e as normas locais.

Monitoramento, observabilidade e SLO

Métricas de provedores/consoadores: lag, throughput, erros, retraias, tempo de processamento.
Logi + trailing (ID correlacionado: 'trace _ id', 'mensagem _ id').
SLO: p99-latência de publicação/entrega, consumer lag, tempo de recuperação após feeds.
Alertas para o crescimento do DLQ, excesso de lag, queda das partições/quórum.

Segurança e Complacência

TLS em trânsito, criptografia de segredos (SOPS/Vault), LCA/RBAC limitado.
Topics/filas individuais para domínios sensíveis (pagamentos, KYC).
Auditoria-logos de publicações/assinaturas, armazenamento de chaves fora do código.
Requisitos regionais (EU/Turquia/LatAm): Retensão, localização de armazenamento, camuflagem.

Alta disponibilidade, resistência a falhas e DR

• Cluster 3-5 corretores mínimo; replication. factor ≥ 3.
• min. insync. réplicas e acks = all para gravações resistentes.
• Replicações cruzadas (MirrorMaker-2) para DR..

• Quorum queues para HA, número par/ímpar de nodo com quórum.
• Federation/Shovel para MJ de replicação, DR.
• Estande frio/quente, testes de mudança.

Desempenho e sintonização

• `linger. ms` и `batch. size 'para batching;' compressão. type` (lz4/zstd).
• 'acks = all', mas monitorar a latência; Tun 'max. in. flight. requests. per. conexion 'com idumpotência.

• Bastam as partições; unidades NVME; grade 10/25G; Configurações GC do JVM.

• Banda de gestão correta, 'max. poll. interval. ms ', pausar as partições ao bacofé.

• Publisher conferms em batches; £ els reutilizar.

• 'prefetch' (por exemplo, 50-300) no tempo de processamento; lazy queues para grandes backlogs.
• Espalhar filas quentes por nodes; Tun TSD/descriptores de arquivo.

Pattern típicos para iGaming

Outbox + Kafka para publicações confiáveis de eventos de domínio (taxa postada, depósito depositado).
RPC para solicitações sincronizadas de integração (comprovação de documento KYC, cálculo de bônus).
Saga Pattern: Orquestra através de eventos (Kafka) e equipes (RabbitMQ) com passos compensadores.
Notificações fan-out de um evento → CRM, antifrode, analista.
Smart-retry webhooks PSP com atrasos progressivos e DLQ.

Migração e arquiteturas híbridas

Comece com RabbitMQ para «operacionalizar», adicione Kafka para eventos e analistas.
Duplique as publicações: serviço → outbox → conector em ambos os sentidos (Kafka + RabbitMQ) antes de se estabilizar completamente.
Progressivamente, transfira os assinantes dos analistas/agregados strim para Kafka Streams/ksqlDB.

Folha de seleção mini-cheque

1. Carga/TPS> dezenas de milhares/segundos? → Kafka.
2. Precisas de retino e ler novamente como uma revista?
3. Rotação flexível, prioridades, entrega adiada, RPC? → RabbitMQ.
4. Ordem de chave rigorosa e skale horizontal → Kafka (chave/partição).
5. Tarefas simples/work-ku com controle de paralelismo → RabbitMQ.
6. O ideal é uma combinação de Kafka (eventos) + RabbitMQ (orquestração).

Exemplos de configurações mínimas

Exemplo: retais retidos e DLQ em RabbitMQ (policy)

Fila de trabalho: 'psp. webhooks. q`

Fila de retrações: 'psp. webhooks. retry. 1m. q '(TTL = 60s, DLX indica para trás o trabalho)

DLQ: `psp. webhooks. dlq`

• `psp. webhooks. q` → `x-dead-letter-exchange=psp. retry. exchange`
• `psp. webhooks. retry. 1m. q` → `x-message-ttl=60000`, `x-dead-letter-exchange=psp. work. exchange`
• `psp. webhooks. dlq '→ monitoramento e análise manual.

Exemplo: top Kafka para apostas

Topic, 'bets. placed. v1 ', partituras: 24, RF = 3, retenções 7 dias.
A chave de mensagem é 'player _ id' ou 'bet _ id' (selecione o que é mais importante para a ordem).
Схема: Protobuf/Avro с `bet_id`, `player_id`, `stake`, `odds`, `ts`, `idempotency_key`.

Testes e qualidade

Testes Contracto de Produção/Consumer + Verificação de Circuitos (Schema Registry).
Chaos-testes: queda de nó, atrasos na rede, split-brain.
Testes de carga com TPS de destino, verificação p99, crescimento de lag e recuperação.

Resumo

Kafka é uma autoestrada de eventos e streaming: ordenamento à chave, retino/compacto, TPS alto, analista em tempo real.
RabbitMQ - Fila operacional de tarefas: routagem flexível, confirmação, prioridades, retraí/DLQ, RPC.
Em iGaming, a melhor prática é o uso complementar: eventos e análises na Kafka, tarefas de integração/orquestração no RabbitMQ, com padrões unificados de esquema, idoneidade, monitoramento e SLO rigorosos.