Dados de Event-Streaming e real-time

(Secção Tecnologia e Infraestrutura)

Resumo curto

Event-Streaming é o processamento e a entrega de eventos no momento em que eles aparecem. Isso significa uma reação instantânea a apostas, depósitos, sinais antifrod, limites de jogo responsável, tabelas de torneios e offs pessoais. Tijolos básicos: pneu de evento (Kafka/Pulsar), processador de streaming (Flink/ksqlDB/Spark Stratured Streaming), CDC de BB transaccional (Debezium), Função Store para ML online e real-time analista (visões materializadas, OLAP).

Onde isso é crítico em iGaming

Antifrod & risco: compilação de transações em <100-300 ms, correlação de pattern comportamentais, bloqueio e escalação.
Jogo responsável: controle de limites, velocidade de perdas, comportamento anormal - alertas e limitações automáticas em tempo real.
Pagamentos: Ventelas estatutárias, webhooks PSP, smart-retry, projeções de balanço, SLA «time-to-wallet».
Jogos Ivents: cálculo de líderes de torneios (sliding janela), rodadas de jogos ao vivo, fita real-time para CRM/marketing.
Personalização: fichas online (RFM, propensity) → campanhas de desencadeamento, push/email em segundos.
Analista operacional: p95/p99 latency, conversão de passos de vórtice, sinais de plataforma health.

Modelos arquitetônicos

Lambda vs Kappa

Lambda: batch (DWH/ETL) + streaming. Além disso, flexibilidade e barata; menos é uma lógica dupla.
Kappa: tudo - como um fluxo de registro (Kafka). Além disso, um único código, uma reigra de eventos; menos - mais rigoroso que os requisitos de infraestrutura.

Prática: para trechos críticos de real-time - Kappa; para relatórios/treinamento ML - contorno batch aditivo.

Linha de montagem de eventos (árbitro)

1. Fabricantes: serviços de apostas/pagamentos publicam eventos de domínio (outbox → Kafka).
2. Pneu: Kafka com partituras de chave ('player _ id', 'bet _ id').
3. CDC: O Debezium puxa as alterações do OLTP (balanços, limites) para a estirpe.
4. Streaming: Flink/ksqlDB/Spark - agregações, janelas, CEP, join's.
5. Tabelas materializadas (Kafka Streams state store/ ksqlDB táveis/Redis), OLAP (ClickHouse/Druid).
6. Consumidores: antifrode, CRM, notificações, dashboard, workflow desencadeado.

Contratos de dados e esquema

Avro/Protobuf + Schema Registry: contratos rígidos, migrações backward-compatível.
Versioning: 'domain. event. v{n}`; proibir alterações quebrantes.
PII: toquenização/criptografia, camuflagem, purpose limitation (GDPR).

Semânticos de entrega e idempotação

At-least-once é um padrão de facto (pode ser duplicado) → é obrigatório idempotent-handling.
Exactly-once em streaming: renovadores de transação Kafka + EOS na Flink/Streams; mais caro, aplicar de forma pontual (dinheiro/saldo).
Outbox + CDC: uma única fonte de verdade do serviço de base de dados, proteção contra gravação dupla.
Dedup: chave ('idempotency _ key'), tabela de dedução com TTL, upsert/merge.

Janelas temporárias e dados «tardios»

• Tumbling - slots fixos (por exemplo, um minuto de rotação).
• Hopping - deslizando a passo (por exemplo, uma janela de 5 min com um passo de 1 min).
• Sessão - por inatividade (sessão do jogador).
• Watermarks: processamento por event-time, tolerância de «tardes» (lateness), evacuação em DLQ/side-output.
• CEP (Complex Event Processing): pattern «A depois B em 3 min», «N eventos em M segundos», «cancelamento/compensação».

Status e zoom

Operadoras de stateful: agregações/joynes mantêm o estado (RocksDB state backend).
Changelog topics: confiabilidade e recuperação state.
Backpressure: ajuste de velocidade automático, limites de sink/外 do sistema.
Distribuição de chaves: chaves quentes (heavy hitters) → key-salting, skew mitigation.

Monitoramento e SLO

SLO fluxo: p99 end-to-end latency (por exemplo, ≤ 2 c), consumer lag válido, disponibilidade ≥ 99. 9%.
Métricas: throughput, lag de partituras, watermark delay, drop/late ratio, backpressure, busy time operadores, GC/JVM.
Alerts: Crescimento do DLQ, watermark atrasado, falhas de checkpoint EOS, raio de fichas online/offline.
Tracing: ID de coreia ('trace _ id', 'mensagem _ id') através de um consoante de produção strim.

Segurança e Complacência

TLS/MTLS, LCA/RBAC em topics/tabelas, segmentação de domínios sensíveis (pagamentos/CUS).
Criptografia PII em trânsito/disco; segredos em Vault/SOPS.
Data retence & locality: armazenamento por região (UE, Turquia, LatAm), apólice de remoção.
Auditoria: quem publicou/leu, reprodutividade dos cenários.

Alta disponibilidade e DR

Kafka: `replication. factor ≥ 3`, `min. insync. replicas ',' acks = all ', replicação cruzada regional (MM2) para DR..
Flink/Streams: checkpoint periódico + savepoint para lançamentos controlados; HA-JobManager.
OLAP: replicação de segmentos, read replicas; testes de failover (game day).

Desempenho e sintonização

Vendedores: batching ('linger. ms`, `batch. size '), compressão (lz4/zstd).
Consoadores: correto 'max. poll. interval, uma pausa das partições no bacofo.
Particionamento: conta partituras do TPS alvo e paralelismo.
State: RocksDB options (block cache/write buffer), NVMe/IOPS, pinning.
Rede: 10/25G, sintonização TCP, contenção n + 1 sink-in.

Implementação: tecnologias-chave

Pneu: Apache Kafka (alternativas Pulsar, Redpanda).
Streaming: Apache Flink, Kafka Streams, ksqlDB, Spark Estrutured Streaming.
CDC: Debezium (MySQL/Postgres), conectores Outbox.
Armazéns de projeções: ksqlDB tantes, Kafka Streams state store, Redis para baixa latência, ClickHouse/Druid/Pinot para OLAP.
Feast ou Feast - Online (Redis) + offline (Parquet/BigQuery), garantia de consistência.

Pattern de design

Outbox → Kafka: cada evento de domínio de uma transação de banco de dados.
Sagas: compensações através de eventos; a orquestra é um strim.
Fan-out: um evento → antifrode, CRM, analista, notação.
Materialize Views: Liderbords, equilíbrio, limites - como tabelas que se atualizam a partir de striptease.
Reprocessing: reprodução de topics para recontagem de unidades/analistas retráteis.

Exemplos (conceitos)

ksqlDB: líderes do torneio (janela 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 (pseudocode): mapeamento antifrode 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);

Testes de qualidade de fluxo

Testes Contracto de Padrão e Evolução (Schema Registry).
Cargas: TPS alvo, p99, comportamento de degradação sink.
Failure/chaos: queda de corretores/nós, atrasos de rede, split-brain.
Deterministic replays: reaproveitamento de topics → resultados iguais.
Fluxo Canary: contorno de verificação de atraso e integridade.

Folha de cheque de implementação

1. Definir SLO (p99 E2E ≤ X, lag ≤ Y, disponibilidade ≥ Z).
2. Normalizar circuitos e chaves (player _ id/bet _ id).
3. Selecionar arquitetura (Kappa para caminhos críticos).
4. Personalizar outbox + CDC e isolar PII.
5. Definir janelas, watermark, late-policy e DLQ/side outputs.
6. Incluir EOS/Idempotação nos caminhos de dinheiro.
7. Digite monitoramento e alertas em lag, watermark, DLQ.
8. Forneça HA/DR. e regulamentos reprocessing.
9. Expandir a Função Store e sincronizar online/offline.
10. Executar game-day: falha e recuperação.

Antipattern

Misturar event-time e processing-time sem uma política consciente.
Falta de governance schema → lançamentos «quebra».
Ignorar late data e chaves quentes.
Falta de estratégia replay e versionização de topics.
Taxas/pagamentos sem idempotency e EOS.

Resumo

Real-time streaming não é um «outro transporte», mas uma forma de pensar: eventos de domínio, SLO claro, contratos de dados, janelas e condições, segurança e observabilidade. Para iGaming um conjunto sustentável - Kafka + Flink/ksqlDB + Debezium + Materialization Views + Função Store. Ele oferece reações milissegundas, coerência de analistas online/offline e complexidade controlada quando a carga aumenta.