Message Queue Server: Kafka y RabbitMQ

Message Queue Server: Kafka, RabbitMQ

(Sección: Tecnologías e Infraestructura)

Resumen breve

• Apache Kafka es un registro de eventos distribuido (log), orientado al procesamiento de streaming, replicación y skaling horizontal a través de lotes.
• RabbitMQ es un corredor de colas AMQP con enrutamiento flexible (exchanges/bindings), prioridades, TTL, confirmaciones y tareas clásicas de colas.

Ambos instrumentos son maduros, pero resuelven diferentes problemas: Kafka - para streams escalables y análisis, RabbitMQ - para la orquestación operativa de tareas, RPC y enrutamiento múltiple.

¿Dónde es apropiado en iGaming?

• Se necesita un alto TPS de eventos (apuestas, eventos de juegos, telemetría) y un skale horizontal a través de los partidos.
• Es importante el re-consum frío/caliente (re-lectura de los datos de la cinta), el retén y el compacto para los agregados (balance, estado del jugador).
• Se necesitan procesos de streaming (Kafka Streams/ksqlDB/Flink) para unidades realtime: líderes de torneos, límites de juego responsable, señales antifraude.

• Se necesitan colas de tareas clásicas: verificación KYC, pagos diferidos/repetidos, envío de correo electrónico/SMS/inserción, webhooks a PSP.
• Enrutamiento flexible (topic/direct/fanout), prioridades, TTL, delay, dead-letter y patrones RPC.
• Se requieren restricciones por consumo estrictas (prefetch/QoS), administración de carga simple y retraídas rápidas.

Resumen frecuente: Kafka para eventos y análisis + RabbitMQ para orquestación e integraciones.

Modelo de datos y enrutamiento

Kafka

Los topics → se rompen en lotes, cada uno es un registro ordenado.
La clave de mensaje define el lote → el orden dentro de la clave.
Los consumidores leen por offset, los grupos de consumidores escalan el procesamiento.
Retiro en tiempo/volumen; log compaction almacena la última versión de la clave.

RabbitMQ

Exchanges (direct/fanout/topic/headers) + bindings → mensajes caen en queues.
Confirmaciones (ack/nack/requeue), confirms de publisher, priorities, TTL, dead-letter (DLX/DLQ).
Quorum queues (Raft) para alta disponibilidad; lazy queues para ahorrar RAM.

Garantías de entrega e idempotencia

At-most-once: sin retrayas; riesgo de pérdida, retraso mínimo.
At-least-once: el estándar predeterminado → es posible duplicados → hendlers idempotentes (clave de consulta/transacción, upsert, dedup-table, outbox).
Exactly-once: en Kafka se logra en conjunto un productor idempotente + topics transaccionales + un consumo coherente, pero más a menudo más caro y complejo; en RabbitMQ - limitado y con huesos. En los flujos reales de pago/tasa, se aplica al-least-once + una estricta idempotencia.

• Idempotency-keys (UUID/ULID) únicos por evento/comando.
• El patrón de outbox en el DB del servicio + Change Data Capture (Debezium) → evitar la «grabación dual».
• Dedup por (clave, created_at) en un setor separado con TTL.

Orden/Orden de

Kafka garantiza el orden dentro del partido. Seleccione la clave para que en una sola clave aparezca toda la «vida» de la entidad (por ejemplo, 'player _ id' para el equilibrio).
El orden RabbitMQ no está estrictamente garantizado en envíos repetidos/varios consumidores; paipelines críticos con el orden - mejor en Kafka o a través de un solo consumidor activo y serialización de flujo.

Diseño de topics y colas

• Granularidad: 'domain. event '(por ejemplo,' payments. deposit. created`).
• Claves: 'player _ id', 'account _ id', 'bet _ id' para ordenar.
• Lotes = N por TPS objetivo (regla: 1 lote ≈ X mensajes/sec/consumer); poner un margen para el crecimiento.
• Retiro: eventos - horas/días; Compactación - para «estados».

• Exchanges por dominios: 'payments. direct`, `risk. topic`.
• Colas para consumidores: 'kyc. checker. q`, `psp. webhooks. retry. q`.
• DLQ para cada cola de trabajo; delay para backoff.
• Prefetch establece el paralelismo, colas quorum - para HA.

Errores, retraídas y DLQ

Clasifique los errores: temporales (red/PSP 5xx) → retraídas; fatal (validación, esquema) → DLQ inmediatamente.
Retroceso exponencial + jitter, límite de retraídas, detección de "poison-pill'.
Retry-queues individuales por pasos (5s, 1m, 5m, 1h).
Controlador DLQ: alert, trace, manualty, re-inject con parche.

Contrato de datos y esquemas

Utilice Avro/Protobuf + Schema Registry (para Kafka es un estándar de facto).
Versificación: cambios compatibles con backward (agregar campos opcionales), prohibición de migraciones disruptivas.
Campos PII: cifrado/tokenización; cumpla con el RGPD y las normas locales.

Monitoreo, observabilidad y SLOs

Métricas de productores/consumidores: lag, throughput, errores, retrases, tiempo de procesamiento.
Logs + traising (ID de correlación: 'trace _ id', 'message _ id').
SLO: p99-latencia de publicación/entrega, registro de consumo válido, tiempo de recuperación después de las falsificaciones.
Alertas sobre el crecimiento de DLQ, exceso de lag, caída de lotes/quórum.

Seguridad y cumplimiento

TLS en tránsito, cifrado de secretos (SOPS/Vault), ACL/RBAC restringidos.
Topics/colas individuales para dominios sensibles (pagos, KYC).
Registro de auditoría de publicaciones/suscripciones, almacenamiento de claves fuera de código.
Requisitos regionales (UE/Turquía/LatAm): retoque, localización de almacenamiento, enmascaramiento.

Alta disponibilidad, tolerancia a fallas y DR

• Clúster de 3-5 corredores mínimo; replication. factor ≥ 3.
• min. insync. replicas y acks = all para registros duraderos.
• Replicación regional cruzada (MirrorMaker-2) para DR.

• Quorum queues para HA, un número par/impar de nodos con quórum.
• Federación/Shovel para la replicación entre centros de datos, scripts DR.
• Banco frío/caliente, pruebas de cambio.

Rendimiento y afinación

• `linger. ms` и `batch. size 'para batcheo;' compresión. type` (lz4/zstd).
• 'acks = all', pero seguir la latencia; tun 'max. in. flight. requests. per. connection 'con idempotencia.

• Bastantes partidos; unidades NVMe; cuadrícula 10/25G; Configuración GC de JVM.

• La gestión de grupo correcta, 'max. poll. interval. ms ', pausa los lotes con el backoff.

• Publisher confirms en batches; channels volver a usar.

• 'prefetch' (por ejemplo, 50-300) según el tiempo de procesamiento; lazy queues para grandes backlogs.
• Extienda las colas calientes por nodos; tun TSD/descriptores de archivos.

Patrones típicos para iGaming

Outbox + Kafka para la publicación confiable de eventos de dominio (apuesta colocada, depósito acreditado).
RabbitMQ RPC para solicitudes sincrónicas de integración (verificación de documentos KYC, cálculo de bonificaciones).
Patrón de saga: orquestación a través de eventos (Kafka) y comandos (RabbitMQ) con pasos compensatorios.
Fan-out notificaciones: de un solo evento → CRM, antifraude, analítica.
Smart-retry PSP webhooks con latencia progresiva y DLQ.

Migraciones y arquitecturas híbridas

Comience con RabbitMQ para «operación», agregue Kafka para eventos y análisis.
Duplicar publicaciones: servicio → outbox → conector en ambos lados (Kafka + RabbitMQ) hasta que esté completamente estabilizado.
Transfiera gradualmente los suscriptores de análisis/agregaciones en streaming a Kafka Streams/ksqlDB.

Mini lista de selección

1. ¿Carga/TPS> decenas de miles/sec? → Kafka.
2. ¿Necesitas retocar y volver a leer como de una revista? → Kafka.
3. Enrutamiento flexible, prioridades, entrega diferida, RPC? → RabbitMQ.
4. Orden estricto en la llave y skale horizontal → Kafka (llave/lote).
5. Tareas simples con control de paralelismo → RabbitMQ.
6. Lo ideal es una combinación: Kafka (eventos) + RabbitMQ (orquestación).

Ejemplos de configuraciones mínimas

Ejemplo: retraídas y DLQ detenidos en RabbitMQ (a través de la política)

Cola de trabajo: 'psp. webhooks. q`

Cola de retiros: 'psp. webhooks. retry. 1m. q '(TTL = 60s, DLX apunta hacia atrás al trabajo)

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 '→ monitoreo y desmontaje manual.

Ejemplo: topic Kafka para apuestas

Topic: 'bets. placed. v1 ', lotes: 24, RF = 3, retiro 7 días.
Clave de mensaje: 'player _ id' o 'bet _ id' (seleccione qué es más importante para el orden).
Схема: Protobuf/Avro с `bet_id`, `player_id`, `stake`, `odds`, `ts`, `idempotency_key`.

Pruebas y calidad

Pruebas de contrato productoras/consumidoras + comprobación de circuitos (Registro de Schema).
Pruebas Chaos: caída de nodo, retardo de red, split-brain.
Correas de carga con TPS objetivo, verificación de p99, crecimiento y recuperación.

los Totales

Kafka es la autopista de eventos y streaming: ordenamiento por clave, retén/compactación, alto TPS, analítica en tiempo real.
RabbitMQ es una cola de tareas operativa: enrutamiento flexible, confirmaciones, prioridades, retrai/DLQ, RPC.
En iGaming, la mejor práctica es el uso complementario: eventos y análisis en Kafka, tareas de integración/orquestación en RabbitMQ, con estándares de circuitos uniformes, idempotencia, monitoreo y SLO rigurosos.