Eventos de feeds reales: arquitectura y seguridad

El Real-Time Fid de eventos es un «sistema circulatorio» de productos con gamificación, antifraude, desencadenantes CRM y pagos. Para que funcione previsiblemente en picos, no duplique premios ni fluya con datos, se necesita una arquitectura rigurosa: desde protocolos y neumáticos hasta firma, idempotencia, presupuesto-alcaparras y observabilidad.

1) Objetivos y requisitos

Fiabilidad: entrega de eventos con un retraso mínimo (p95 ≤ 250 ms ingest, p95 ≤ 1-2 con el consumidor).

Entrega: at-least-once transporte + lógica exactly-once a través de la idempotencia.

Orden: ordenar por clave (normalmente 'user _ id') con ventanas de reordenación.

Seguridad: MTLS, HMAC/JWT, rotación de llaves, protección contra replay/duplicados, minimización de PII.

Escala: sharding horizontal, backpressure, rate limiting, DLQ/relay.

Capacidad de administración: registro de schema, versionamiento, migración sin tiempo de inactividad.

Cumplimiento: auditoría (WORM), RG/KYC gates, políticas geo, GDPR/anonimización.

2) Arquitectura de referencia (capa por capa)

1. Productores (fuentes): servidor de juegos, billetera/pago, KYC/AML, SDK cliente (web/iOS/Android).

2. API Gateway (Ingress): recepción de HTTP/gRPC, validación de circuitos, autenticación, HMAC/MTLS, normalización del tiempo.

3. Queue/Stream: Kafka/Rabbit/Cloud Pub/Sub - buffering, partición por 'user _ id'.

4. Stream Processor: normalizador, enriquecimiento, enrutamiento de temas, banderas anormales/antibot, registro idempotente.

5. Consumidores: Rules/Scoring, Reward Orchestrator, conectores CRM/CDP, antifraude, sink 'i analíticos.

6. Almacenamiento: eventos crudos (immutable), escaparates, índice para la idempotencia, auditoría-registro.

7. Observabilidad: métricas, registros, trazados, alertas; panics → DLQ.

8. Admin Plane: registro de schema, llaves/secretos, RBAC/ABAC, fichflags, servicio de replay.

3) Protocolos de entrega: cuándo utilizar

HTTP/JSON (server-to-server webhooks): simplemente, compatible, es bueno para socios externos. Añadir HMAC + idempotencia.

gRPC/Protobuf: baja latencia, circuitos estrictos, bidi-streams para servicios internos.

WebSocket/SSE: inserción al cliente, suscripciones de liderazgo de UI y progreso.

CDC/Kafka Connect: cuando las fuentes son DB/billeteras, no servicios comerciales.

Recomendación: el perímetro exterior es HTTP + HMAC + MTLS; dentro - gRPC/Protobuf.

4) Modelo de eventos y convenciones

json
{
"event_id": "e_01HF3Z8Z7Q8Q2K",  "event_type": "bet",  "schema_version": "1. 3. 0",  "occurred_at": "2025-10-24T11:37:21Z",  "ingested_at": "2025-10-24T11:37:21. 183Z",  "key": { "user_id": "u_12345" },  "ctx": {
"session_id": "s_778",   "platform": "ios",   "geo": "TR",   "device_fp": "fp_4a1..."
},  "payload": {
"game_id": "slot_wolf",   "bet": 0. 5,   "win": 1. 25,   "currency": "EUR",   "provider": "GameCo"
},  "sig": {
"algo": "HMAC-SHA256",   "kid": "k_2025_10",   "ts": 1730061441,   "mac": "c7b7b3...f1"
}
}

Reglas:

Dos tiempos: 'occurred _ at' (fuente) e 'ingested _ at' (gateway). Permita la deriva del reloj ± 300 s.
La clave de enrutamiento es lo que determina el orden (normalmente 'user _ id').
PII sólo en 'ctx '/' payload' por el principio de minimización; para atributos sensibles - tokenización.

5) Entrega, orden e idempotencia

At-least-once transporte → es posible duplicar y reordenar.

Exactly-once lógica: mantener la tabla de idempotencia con un índice único por '(event_id)' y/o '(user_id, source_seq)'; repetición - no-op.

SQL-sketch:

sql
CREATE TABLE event_log (
event_id TEXT PRIMARY KEY,  user_id TEXT,  event_type TEXT,  occurred_at TIMESTAMPTZ,  payload JSONB
);

-- inserción con protección contra tomas
INSERT INTO event_log(event_id, user_id, event_type, occurred_at, payload)
VALUES (:event_id,:user_id,:event_type,:occurred_at,:payload)
ON CONFLICT (event_id) DO NOTHING;

Orden: partición de flujo por 'user _ id' + redering window 60-120 s en el procesador. Más tarde, los eventos que llegan caen en el «re-juego» (replay) de las funciones correctivas.

6) Backpressure y gestión de picos

Token-bucket rate limiting на ingress (per-IP, per-partner, per-key).

Circuito breaker: a 5xx de los consumidores internos → degradación (dropout de eventos opcionales, colas aumentan los intervalos retray).

DLQ: mensajes permanentemente erróneos (esquema bit, firma inválida, TTL de firma excedida).

Replay service: Replice selectivo desde DLQ por 'event _ id '/intervalo de tiempo.

7) Esquemas y evolución: cómo no «romper» el prod

Schema Registry: JSON Schema/Protobuf; políticas de compatibilidad: backward para productores, forward para consumidores.

Versioning: 'schema _ version', mayor - sólo a través de fichflag y doble entrada (dual-write).

Contratos: promoción del circuito después del periodo canario y de las métricas verdes.

YAML ejemplo de regla de validación:

yaml compatibility:
enforce: true mode: backward blocked_fields:
- payload. ssn
- payload. card_number required_fields:
- event_id
- event_type
- occurred_at

8) Modelo de amenazas y protección

Amenazas: reemplazo de cuerpo, repetición (replay), fuga PII, compromiso de clave, schema-poisoning, DoS, MITM, firma de stripping.

Protección:

MTLS en el perímetro: certificados de cliente de corto plazo, CRL/OCSP.
Firma HMAC del cuerpo + 'X-Timestamp' y TTL (± 300 s).
JWT (client credentials/OAuth2) - para autorización y restricciones de scope.
Rotación de claves (KMS): 'kid' en el título; Plan de rotación de 30-90 días; verificación doble en la ventana de migración.
Nonce/idempotencia: 'X-Request-Id' para solicitudes de subproductos (pagos, bonificaciones); almacene TTL durante un tiempo.
Pinning Content-Type, tamaño máximo de cuerpo, IP/ASN allow-list para integraciones críticas.
Auditoría WORM de todos los títulos raw-payload + entrantes (almacenamiento inmutable).

Ejemplo de validación HMAC (pseudocódigo):

python body = request. raw_body ts = int(request. headers["X-Timestamp"])
assert abs(now() - ts) <= 300 # анти-replay kid = request. headers["X-Key-Id"]
secret = kms. fetch(kid)
mac = hmac_sha256(secret, body)
assert hmac_eq(mac, request. headers["X-Signature"])

9) Privacidad, PII y RG/KYC

Minimización: PII para pasar por enlace-token (5-15 minutos) en lugar de en línea; la edición/anonimización en los logotipos en bruto está prohibida - use los soportes PII individuales.

Acceso: ABAC por atributos de jurisdicción y función; todas las lecturas están en el registro de auditoría.

GDPR: el derecho de eliminación se implementa a través de key-mapping para borrar PII sin romper los hechos de los eventos.

RG/KYC: los eventos que requieren la emisión de recompensas valiosas, sólo se pierden con el nivel KYC válido y las banderas RG «OK».

10) Observabilidad y SLO

SLO (ejemplo):

Ingest p95 ≤ 250 ms; end-to-end p95 ≤ 2 с; Error ≤ 0. 1 %/día.
Error de firma (HMAC/JWT) ≤ 0. 02% del flujo total.
DLQ fill rate ≤ 0. 1%; «duplicados» después de la idempotencia ≤ 0. 005%.

Dashboard:

RPS por fuente, p50/p95 latencia, 4xx/5xx, errores de firma, tiempo-skew.
Lag por lotes, reciclaje/sec, fill DLQ, retries, relés de volumen.
Esquemas: porcentaje de mensajes por versión, infracciones de compatibilidad.
Seguridad: frecuencia rps-throttle, circuit-breakers, anomalías IP/ASN.

Alertas (ejemplos):

Flujo SRM (distorsión brusca del tráfico de una sola fuente).
Latencia p95> objetivo 5 min +, crecimiento DLQ> X/min.
Errores de firma> Y ppm, ráfaga de repeticiones 'X-Request-Id'.
Drift reloj> 120 s en la fuente.

11) Multi-región y tolerancia a fallas

Regiones Active-Active, routing global (GeoDNS/Anycast), sticky-key por 'user _ id' → región.

Topic de replicación regional cruzada para eventos críticos (efectivo, KYC).

Blast radius: aislamiento por tenantes/marcas, presupuestos individuales y claves.

Plan DR: RPO ≤ 5 min, RTO ≤ 30 min; ensayos regulares.

12) Políticas de retiro y replay

Eventos crudos: 7-30 días (costo), unidades/vitrinas - más tiempo.

El replay solo está permitido por el runbook firmado (quién, qué, por qué, rango de tiempo).

El replay siempre va a la nueva versión stream con la bandera 'replayed = true' para la transparencia analítica.

13) Ejemplos de configuraciones

Ingress (estilo NGINX) límites:

nginx limit_req_zone $binary_remote_addr zone=req_limit:10m rate=300r/s;
limit_req zone=req_limit burst=600 nodelay;

client_max_body_size 512k;
proxy_read_timeout 5s;

Kafka (ejemplo):

properties num. partitions=64 min. insync. replicas=2 acks=all retention. ms=604800000  # 7 days compression. type=zstd

Política de claves (KMS):

yaml rotation_days: 45 grace_period_days: 7 allow_algos: ["HMAC-SHA256"]
key_scopes:
- topic: "wallet_events"
producers: ["wallet-svc"]
consumers: ["ledger-svc","risk-svc"]

14) Lista de comprobación de inicio del feed real-time

MTLS en el perímetro, HMAC/JWT, rotación de llaves ('kid').
Idempotencia en la lógica (claves únicas, upsert/ON CONFLICT).
Partición por 'user _ id', redering window, servicio de réplica.
Schema registry + políticas de compatibilidad; dual-write bajo mayores-apdates.
Rate limiting, circuit breakers, DLQ + rugido manual.
Observabilidad: SLO, alertas por firma/latencia/DLQ/lag.
Política de PII/anonimato, ABAC, auditoría WORM.
DR/multi-región, ensayos de feilover.
Runbooks: incidentes, réplica, retroceso de diagramas/llaves.

15) Mini caso (sintético)

Contexto: pico de torneos, 120 a RPS, 64 partidos, 2 regiones Active-Active.

Total en 4 semanas: ingest p95 210 ms, e2e p95 1. 6 c; DLQ 0. 05%; errores de firma 0. 009%; duplicados después de la idempotencia 0. 003%.

Incidente: la deriva del reloj en la pareja (−9 min) → una ráfaga anti-replay. Circuit breaker tradujo el flujo en un endpoint «buffer», partner-health alertó al CSM; después del azul NTP - el retoque de la ventana de 12 min a todos los consumidores. No hay pérdidas ni pagos dobles.

16) Resumen

Un fideicomiso fiable en tiempo real no es "solo webhooks'. Se trata de un sistema de capas con contratos claros: transporte at-least-once + exactly-once lógico, esquemas-mayúsculas y versionados, MTLS/HMAC/JWT y rotación de llaves, backpressure/DLQ/relay, minimizar el PII y realizar auditorías rigurosas. Al seguir estas prácticas, obtendrá un flujo de eventos rápido, seguro y predecible en el que podrá construir con confianza gamificación, antifraude, CRM y pagos.