Event-Streaming y datos en tiempo real

(Sección: Tecnologías e Infraestructura)

Resumen breve

Event-Streaming es el procesamiento y entrega de eventos en el momento en que aparecen. Para iGaming, esto significa una respuesta instantánea a apuestas, depósitos, señales antifraude, límites de juego responsables, mesas de clasificación y offers personales. Ladrillos básicos: bus de eventos (Kafka/Pulsar), motor de flujo (Flink/ksqlDB/Spark Structured Streaming), CDC de transaccional DB (Debezium), Feature Store para línea ML y análisis en tiempo real (representaciones materializadas, OLAP).

Donde es crítico en iGaming

Antifraude & Riesgo: puntuación de transacciones en <100-300 ms, correlación de patrones de comportamiento, bloqueo y escalamiento.
Juego responsable: control de límites, velocidad de pérdida, comportamiento anómalo - alertas y auto-restricciones en tiempo real.
Pagos: ventiles de estado, webhooks PSP, smart-retry, proyecciones de balances, SLA «time-to-wallet».
Eventos de juego: cálculo de líderes de torneos (ventana deslizante), rondas de juegos en vivo, cintas en tiempo real para CRM/marketing.
Personalización: fiches en línea (RFM, propensity) → campañas de activación, push/email en segundos.
Análisis operativo: p95/p99 latencia, conversión de pasos de embudo, señales de salud de la plataforma.

Modelos de arquitectura

Lambda vs Kappa

Lambda: batch (DWH/ETL) + streaming (operativo). Además - flexibilidad y «barato» de la bolsa; menos - doble lógica.
Kappa: todo es como un flujo de una revista (Kafka). Además, un código único, un reigrama de eventos; menos - requisitos de infraestructura más estrictos.

Práctica: para contornos críticos de tiempo real - Kappa; para reporting/ML-learning - contorno de batch adicional.

Transportador de eventos (referencia)

1. Fabricantes: los servicios de apuestas/pagos publican eventos de dominio (outbox → Kafka).
2. Bus: Kafka con lotes de claves ('player _ id', 'bet _ id').
3. CDC: Debezium saca los cambios de OLTP (balances, límites) a la corriente.
4. Procesamiento en streaming: Flink/ksqlDB/Spark - agregaciones, ventanas, CEP, join 's.
5. Proyecciones: tablas materializadas (Kafka Streams state store/ksqlDB tables/Redis), OLAP (ClickHouse/Druid).
6. Consumidores: antifraude, CRM, notificaciones, dashboards, workflow desencadenante.

Contratos de datos y esquemas

Avro/Protobuf + Schema Registry: contratos estrictos, migración compatible con backward.
Versioning: 'domain. event. v{n}`; prohibir los cambios rompedores.
PII: tokenización/encriptación, enmascaramiento, limitación de puros (GDPR).

Semánticas de entrega e idempotencia

At-least-once es un estándar de facto (duplicados posibles) → es obligatorio idempotent-handling.
Exactly-once en streaming: productoras transaccionales Kafka + EOS en Flink/Streams; más caro, aplicar puntualmente (dinero/saldo).
Outbox + CDC: una única fuente de verdad del servicio DB, protección contra grabación dual.
Dedup: clave ('idempotency _ key'), tabla de deduplicación con TTL, upsert/merge.

Ventanas temporales y datos «tardíos»

Ventanas:

Tumbling - ranuras fijas (por ejemplo, minuto de rotación).
Hopping - deslizarse en incrementos (por ejemplo, una ventana de 5 min en incrementos de 1 min).
Sesión - por inactividad (sesión del jugador).
Watermarks: procesamiento por event-time, tolerancia «tardía» (lateness), evacuación en DLQ/side-output.
CEP (Complex Event Processing): patrones «A luego B en 3 min», «N eventos en M segundos», «cancelación/compensación».

el Estado y masshtabirovanie

Operadores Stateful: agregaciones/joynes mantienen el estado (RocksDB state backend).
Changelog topics: fiabilidad y recuperación del estado.
Backpressure: velocidad de ajuste automático, límites en el sistema de sink/外.
Distribución de claves: teclas calientes (heavy hitters) → key-salting, skew mitigation.

Monitoreo y SLO

Flujo de SLO: p99 end-to-end latency (por ejemplo, ≤ 2 s), consumer lag válido, disponibilidad ≥ 99. 9%.
Métricas: throughput, log por lotes, watermark delay, drop/late ratio, backpressure, busy time operators, GC/JVM.
Alertas: crecimiento de DLQ, retraso de watermark, fallas de EOS de Cheekpoints, desenmascaramiento de fichas en línea/fuera de línea.
Treking: ID de corea ('trace _ id', 'message _ id') a través de un consumidor de streaming de producción.

Seguridad y cumplimiento

TLS/MTLS, ACL/RBAC en topics/tablas, segmentación de dominios sensibles (pagos/CUS).
Cifrado PII en tránsito/en disco; secretos en Vault/SOPS.
Data retention & locality: almacenamiento por región (UE, Turquía, LatAm), póliza de eliminación.
Auditoría: quién publicó/leyó, la reproducibilidad de los scripts.

Alta disponibilidad y DR

Kafka: `replication. factor ≥ 3`, `min. insync. replicas ',' acks = all ', replicación cruzada regional (MM2) para DR.
Flink/Streams: checkpoint + savepoint periódicos para lanzamientos controlados; HA-JobManager.
OLAP: replicación de segmentos, read replicas; pruebas de failover (día de juego).

Rendimiento y afinación

Productores: batching ('linger. ms`, `batch. size '), compresión (lz4/zstd).
Consumers: correcto 'max. poll. intervalo ', una pausa de lotes en el bacoff.
Partitura: cuenta de lotes de TPS objetivo y concurrencia.
State: RocksDB options (block cache/write buffer), NVMe/IOPS, pinning.
Red: 10/25G, afinación TCP, contención de n + 1 consultas sink.

Implementación: tecnologías clave

Neumático: Apache Kafka (alternativas: Pulsar, Redpanda).
Procesamiento en streaming: Apache Flink, Kafka Streams, ksqlDB, Spark Structured Streaming.
CDC: Debezium (MySQL/Postgres), conectores Outbox.
Almacenes de proyección: ksqlDB tables, Kafka Streams state store, Redis para baja latencia, ClickHouse/Druid/Pinot para OLAP.
Feast: Feast o propio - online (Redis) + offline (Parquet/BigQuery), garantía de consistencia.

Patrones de diseño

Outbox → Kafka: cada evento de dominio de una transacción de DB.
Sagas: compensaciones a través de eventos; orquestación - stream.
Fan-out: un evento → antifraude, CRM, analítica, notificación.
Vistas materializadas: tablas de liderazgo, balance, límites - en forma de tablas que se actualizan desde el stream.
Reprocesamiento: reproducir topics para volver a calcular agregados/análisis retro.

Ejemplos (conceptos)

ksqlDB: líderes del torneo (ventana deslizante)

sql
CREATE STREAM bets_src (
bet_id VARCHAR KEY,
player_id VARCHAR,
amount DOUBLE,
ts BIGINT
) WITH (KAFKA_TOPIC='bets. placed. v1', VALUE_FORMAT='AVRO', TIMESTAMP='ts');

CREATE TABLE leaderboard AS
SELECT player_id,
SUM(amount) AS total_stake,
WINDOWSTART AS win_start,
WINDOWEND  AS win_end
FROM bets_src
WINDOW HOPPING (SIZE 10 MINUTES, ADVANCE BY 1 MINUTE)
GROUP BY player_id
EMIT CHANGES;

Flink (pseudocódigo): puntuación antifraude c late-events

java stream
.assignTimestampsAndWatermarks(WatermarkStrategy. forBoundedOutOfOrderness(Duration. ofSeconds(10)))
.keyBy(e -> e. playerId)
.window(SlidingEventTimeWindows. of(Time. minutes(5), Time. minutes(1)))
.aggregate(scoreFunction, processWindow)
.sideOutputLateData(lateTag)
.addSink(riskTopic);

Pruebas de calidad de flujo

Pruebas de contrato de circuitos y evolución (Registro Schema).
Carga: objetivo TPS, p99, comportamiento de degradación sink.
Failure/chaos: caídas de corredores/nodos, retardos de red, split-brain.
Respuestas detallistas: volver a correr los topics → los mismos resultados.
Canary-streams: esquema de comprobación de latencia e integridad.

Lista de comprobación de implementación

1. Definir SLO (p99 E2E ≤ X c, lag ≤ Y, disponibilidad ≥ Z).
2. Estandarizar esquemas y claves (player_id/bet_id).
3. Seleccionar arquitectura (Kappa para trazados críticos).
4. Configurar outbox + CDC y aislar PII.
5. Especificar ventanas, watermark, late-policy y DLQ/side outputs.
6. Incluir EOS/idempotencia en las rutas monetarias.
7. Introduzca el monitoreo y alertas en lag, watermark, DLQ.
8. Proporcionar HA/DR y reglamentos de reprocesamiento.
9. Implementar Feature Store y sincronización en línea/fuera de línea.
10. Pasar el día del juego: failover y recuperación.

antipatterny

Mezclar event-time y processing-time sin una política consciente.
Ausencia de schema governance → lanzamientos «rompedores».
Ignora los datos late y las «claves de acceso rápido».
No hay estrategia de respuesta y versificación de topics.
Apuestas/pagos sin idempotencia y EOS.

los Totales

El streaming en tiempo real no es «un transporte más», sino una forma de pensar: eventos de dominio, SLO claros, contratos de datos, ventanas y estado, seguridad y observabilidad. Para iGaming, el conjunto sostenible es Kafka + Flink/ksqlDB + Debezium + Materialized Views + Feature Store. Proporciona respuestas milisegundas, consistencia de análisis en línea/fuera de línea y complejidad controlada en el crecimiento de la carga.