Arquitectura de microservicios

1) Por qué microservicios en iGaming

Velocidad de cambio: lanzamientos independientes de los equipos (pagos, contenido, riesgo, torneos).
Fiabilidad: la falla de un servicio no valora todo el producto (límites de falla).
Escala: skale horizontal de dominios «calientes» (billetera, lobby, streams).
Cumplimiento: segregación de datos por regiones/jurisdicciones.

Cuando no vale: pequeño comando/volumen, sin prácticas DevOps, débil automatización de pruebas - entonces el monolito modular es mejor.

2) Dominios, límites y equipos (DDD + Topologies Team)

Contornos de dominio: Cuenta/Perfil, CUS/Cumplimiento, Pagos/Billetera, Contenido/Agregación de Juegos, Bonos/Misiones, Torneos, Marketing/CRM, Informes/BI.
Bounded Context = contrato sobre el modelo de datos y el lenguaje.
Flujos de cambios ↔ comando: un comando = un esquema + sus SLO.
BFF (Backend for Frontend): fachadas individuales bajo Web/Mobile/Partner para no recoger la «orquestación» en el cliente.

3) Comunicaciones: Sincrón vs asinchron

Sincrón (NAT/gRPC): cuando se necesita una respuesta inmediata (verificación de límites al depositar).
Asinchron (Kafka/NATS/SQS): eventos y procesos de fondo (acumulación de cashback, boletines, actualización de calificaciones).

• Ruta crítica = mínimo de hopes de red.
• Integración entre dominios - a través de eventos y APIs contractuales.
• No construir «cadenas de 5 + llamadas sincrónicas» en línea → utilizar EDA/sagas.

4) Contratos y versificación

Contrato-primero: OpenAPI/AsyncAPI + Schema Registry (Avro/JSON Schema).
SemVer + compatibilidad: agregar campos no rompe clientes.
Contratos de conducción de consumo (CDC): verificaciones automáticas en CI (contra regresiones).
Política de depreciación: ventana de soporte (12-18 meses), telemetría según versiones antiguas.

5) Eventos, sagas y consistencia

Outbox/Transaction Log Tailing: registro atómico «datos + evento».

• Orquestación (coordinador central) para pagos/retiros.
• Coreografía (reacción a eventos) para bonos/misiones.
• Idempotencia: claves en 'entityId + action + nonce', almacenamiento del registro dedup.
• Consistencia: «externa» - a través de eventos; «interno» - transacciones dentro del servicio.

6) Datos y almacenamiento

Principio «propio»: cada servicio posee su propio DB (aislamiento de circuitos).

• Transacciones/balances - relacionales (PostgreSQL) con invariantes estrictos.
• Eventos/registro - append-only (Kafka/Redpanda).
• Caché/sesiones - Redis/KeyDB; Líderes - Redis Sorted Sets.
• La búsqueda es OpenSearch/Elastic.
• Proyecciones materializadas para lectura (CQRS): listas/informes rápidos.

7) Confiabilidad y sostenibilidad

Timeouts/Retry with jitter/Retry-budget sólo para operaciones idempotentes.
Circuit-breaker/Outlier-ejection entre servicios.
Bulkhead: grupos separados en «ruidosos» apestrimes.
Rate limits per-client/route, backpressure (503 + Retry-After).
Dead-letter + poison-message handling en colas.

8) Observabilidad (Observabilidad)

Seguimiento: OpenTelemetry ('trace _ id' a través de la shlyuz→servisy→BD).
Métricas: RPS, p50/p95/p99, error rate 4xx/5xx, saturación (CPU/amb/queue), métricas de negocio (TTP, TtW).
Registros: JSON estructural, enmascaramiento PII/PAN/IBAN, corulación por 'trace _ id'.
SLO/alertas: por ruta/función (por ejemplo, 'Depósito p95 ≤ 300 ms',' éxito ≥ 98. 5%`).

9) Seguridad y cumplimiento

Zero-Trust: mTLS servis↔servis (SPIFFE/SPIRE), certificados de vida corta.
AuthN/Z: OAuth2/JWT (aud/scope/amb), delimitación de roles atribuibles.
Secretos: KMS/Secrets Manager/Sealed Secrets, rotación de claves.
GDPR/localización de datos: clústeres regionales, geo-fencing en la puerta de enlace API.
Auditoría: registros sin cambios (WORM), seguimiento de acciones administrativas.

10) Implementación y lanzamientos

Contenedores/K8s: un servicio = un deploy; recursos/límites; PodDisruptionBudget.
CI/CD: linternas, pruebas de unidad/contrato/integ, scan de seguridad, SBOM.
Lanzamientos: canary/blue-green/shadow, migraciones de esquemas a través de expand-and-contract.
Auto scale: HPA por CPU + RPS + p95 + queue-depth; drain cuando se contrae.

11) Rendimiento y costo

Perfilando: p95/99 «por servicios y métodos», gráficos flame.
Caché: read-through/write-through; TTL/discapacidad por eventos.
Ubicación de datos: mantenga los datos calientes cerca del cálculo.
FinOps: target de carga 60-70%, "warm pools', auto-pausa de los workers inactivos.

12) Plantillas de dominio (iGaming)

12. 1 Pagos/Billetera

Servicios: 'payments-gw' (fachada), 'wallet', 'psp-adapters-', 'fraud-check'.
Flujo: 'init → reserve → capture/rollback' (saga).
События: `PaymentInitiated`, `PaymentAuthorized`, `PaymentSettled/Failed`.
Idempotencia: 'Idempotency-Key', dedoop en 'wallet'.

12. 2 CUS/Cumplimiento

Сервисы: `kyc-flow`, `doc-storage`, `sanctions-check`, `pep-screening`.
События: `KycSubmitted/Approved/Rejected`, `RiskScoreUpdated`.
Auditoría y ETA: cola de tareas, caso de tiempo en línea, post-acciones.

12. 3 Bonos/Misiones

Servicios: 'bonus-engine', 'wallet-bonus', 'elegibilidad'.
Coreografía: 'BetPlaced → BonusEngine → BonusGranted → WalletCredited'.
Protección contra abusos: subvenciones idempotent, límites, simulador de reglas.

12. 4 Torneos/Tablas de Liderazgo

Servicios: 'tournament-svc', 'scoring', 'leaderboard'.
Almacenamiento: Redis ZSET + «resbalón» periódico en OLAP.
События: `ScoreUpdated`, `TournamentClosed`, `RewardIssued`.

13) Ejemplo «contrato + evento» (simplificado)

OpenAPI (fragmento) - Wallet

yaml paths:
/v1/wallet/{userId}/credit:
post:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/CreditRequest'
responses:
'202': { description: 'Enqueued' }
components:
schemas:
CreditRequest:
type: object required: [amount, currency, reason, idempotencyKey]
properties:
amount: { type: number }
currency: { type: string, example: UAH }
reason: { type: string, enum: [Deposit, Bonus, Adjustment] }
idempotencyKey: { type: string }

AsyncAPI (fragmento) - evento

yaml channels:
wallet. credit. applied:
publish:
message:
name: WalletCreditApplied payload:
type: object required: [userId, amount, currency, sourceEventId]

14) Pruebas

Unit/Property-based para reglas de dominio.
CDC (Nat/Assertible) - Pruebas de contrato de proveedores/consumidores.
Integración con corredores locales (Testcontainers).
E2E flow crítico (registratsiya→depozit→start igry→vyvod).
Pruebas Chaos/Failover: desconexión PSP/caída del bróker/pérdida de zona.

15) Métricas y SLO (mínimo)

Disponibilidad de servicios: '≥99. 9% 'para pago/billetera.
Latency p95: API de ruta crítica ≤ 300-500 ms.
Error budget: 0. 1–0. 5% por trimestre, burn-alerts.
Colas: lead time evento (produce→consume), DLQ ≤ 0. 1%.
Negocios: TTP, TtW, FTD-éxito, KYC-TtV.

16) Hojas de cheques

Diseño de servicios

• Límite de dominio claro y propietario de datos.
• Contratos OpenAPI/AsyncAPI + esquemas en Registry.
• SLO/alertas definidas; métricas/tracks/logs incorporados.
• Políticas de taimautas/retraídos/idempotentes.
• Migraciones de esquemas: expand-and-contract.

Antes

• Las pruebas de integración de unidad/CDC/son verdes.
• Ruta canaria y plan de retroceso.
• Rate-limits/rutas de peso personalizadas.
• Los secretos/claves/certificados son rotatorios.
• Banderas de Ficha y follbacks preparados.

17) Anti-patrones

Red como bus de datos: cadenas síncronas profundas en lugar de eventos.
Un «dios» común -BD en todos los servicios.
Falta de idempotencia → doble amortización/devengo.
Lanzamientos oscuros sin telemetría y kill-switch.
Sesionalidad oculta (pegajosidad en todas partes en lugar de estado externo).
Contratos «en código» sin versión y CDC.
La lógica en la puerta de enlace API en lugar de los servicios (gateway = slim).

18) Migración desde el monolito (Strangler Fig)

1. Resaltar la fachada-pasarela y el primer contorno (por ejemplo, pagos).
2. Quita la lógica binaria (outbox) del monolito a los eventos.
3. Transfiera progresivamente los endpoints a un nuevo servicio (enrutamiento/pesos canarios).
4. Comprimir el monolito al «núcleo» y desactivar.

19) Pila e infraestructura (ejemplo)

Comunicaciones: NAT/gRPC, Kafka/NATS; Schema Registry.
Almacenamiento: PostgreSQL, Redis, OpenSearch, S3/MinIO; OLAP — ClickHouse/BigQuery.
Contenedores/orquestación: Docker, Kubernetes (Ingress/Gateway), Mesh de servicio (Istio/Linkerd) si es necesario.
Puerta de enlace: Envoy/Kong/Traefik/NGINX.
CI/CD: GitHub Actions/GitLab CI + ArgoCD/Flux; Pact/OWASP/ZAP.
Observability: OpenTelemetry, Prometheus, Tempo/Jaeger, Loki.

20) Parche final

Diseñe los límites según los dominios y la responsabilidad de los datos.
Sincrón - sólo donde se necesita una respuesta ahora; el resto son eventos.
Contratos/esquemas/CDC - seguro contra regresiones.
Sagas + outbox + idempotencia es la base de la fiabilidad.
La observabilidad y el SLO no son una opción, sino un criterio «listo».
Lanzamientos a través de canary/blue-green, migraciones - expand-and-contract.
Seguridad/cumplimiento: mTLS, JWT, KMS, datos regionales.
Primero el monolito modular, luego la evolución... si la escala y el equipo están listos.