Operaciones y Administración → Ampliación de la infraestructura operativa

Ampliación de la infraestructura operativa

1) Por qué y qué considerar «escalar»

La escala es la capacidad del sistema de la plataforma para aumentar el ancho de banda (RPS/TPS, connects, IOPS, throughput) y la cantidad de datos sin perder SLO y con un costo controlado. Para iGaming/Fintech, esto es directamente sobre el dinero: conversión de depósitos/apuestas, juegos en vivo y cálculos.

• Mantener SLO a X veces el aumento de la carga y los picos estacionales.
• Proporcionar un tiempo de escala predecible (minutes, not hours).
• Ahorre economía: costo/RPS, costo/transacción, eventos de costo/1k.

2) Principios de la plataforma escalable

1. Horizontal-primero: división en servicios pequeños, sin estado; estado - en clústeres de datos.
2. Back-pressure y colas: alisado de ráfagas, protección contra «tormentas».
3. Almacenamiento en caché en todas las capas: client/edge/service/DB.
4. Idempotencia y repetibilidad: retiros seguros, outbox, dedoop.
5. Dependencias con restricciones: timeouts, breakers, aislamiento de bulkhead, rate-limits.
6. Observabilidad por señales de capacidad: headroom, p95/p99, lag, connects, cupos.
7. Auto-escalado con RAEs: HPA/VPA/Cluster Autoscaler + stop-conditions.
8. Multi-región por diseño: zonas blast independientes, datos locales, failover sostenibles.

3) Planificación de la capacidad: cómo «contar cuánto se necesita»

Las entradas del modelo son: TPS de pico de destino, perfil de tráfico (por hora), «rutas críticas», ratios de visitas en caché, payload's promedio, SLO y límites de proveedores.

• RPS → CPU/pods: 'pods = RPS p99_time/efficient _ CPU _ in _ pode' (con un margen del 30-50%).
• Colas: 'mínima _ velocidad _ consumers ≥ pico _ velocidad _ productores 1. 2`.
• DB connects: 'max _ conns = pools _ servicios activos media _ pool _ size 1. 3`.
• Caché: tamaño = «hot working-set en N minutos» + 20-30% stock.
• Egress/CDN: pico egress = pico de solicitudes tamaño de respuesta promedio (considerar compresión).

Headroom: meta 20-40% en el pico (por capas). Por debajo del 15% →, el disparador "capacity uplift'.

4) Capas y patrones de zoom

4. 1 Edge / CDN / WAF

Caché en el borde (TTL + SWR), equilibrio geográfico, compresión, HTTP/2/3.
Rate-limits en el perímetro por IP/JWT/clave, protección contra ráfagas.
Fan-out de eventos (jackpots, alertas en vivo) a través de corredores/canales pub/sub.

4. 2 gateway/Backend-for-Frontend API

Escalado horizontal a través de statles-pods, grupos dedicados a downstream.
HPA por métricas de negocio: RPS, p99, cola en el grupo de trabajo - no sólo CPU.

4. 3 Colas asíncronas/streaming (Kafka/Rabbit/Pulsar)

Escala por lotes y consumeres; evitar skew (llaves y distribución).
Lag-alerts + auto-escalado consumers; DLQ y topics retry.
Retention bajo SLA de reconsilación y replay.

4. 4 Cachés (Redis/Memcached)

Modos de clúster, réplicas, políticas de eviction (LFU), multiget, pipeline.
Separación de tareas de fondo y hot-key, límites de clientes y políticas de memoria máxima.

4. 5 Bases de datos

Lectura de réplicas y enrutamiento de lecturas, conexión pooling.
Charding por región/tenante/rango de claves.
CQRS: entradas - por maestro/líder, lecturas - en réplicas.
Indexación y ejecución de escritura de bateo (outbox → stream → sink).
Archivado y datos fríos/calientes (tiering).

4. 6 Almacenamiento de archivos/objetos

Subprocesos múltiples, descargas múltiples, CDN-front, transformaciones asíncronas.
Cuotas del proveedor, limpieza de «colas» y presupuesto de egresos.

4. 7 Proveedores (PSP/KYC/estudio)

Multi-proveedor y enrutamiento por cuotas/SLO/costo.
Circuito breaker + rate-limit para cada proveedor, cola de retiros, «modos grace».

5) Auto-zoom y gard railes

• HPA: метрики `rps_per_pod`, `queue_depth`, `p99_latency`; `targetAverageValue`.
• AVA: recomendaciones sobre recursos; actualizar fuera del pico.
• Cluster Autoscaler: perfiles de grupos nod (spot + on-demand) con prioridades.
• PodDisruptionBudget/TopologySpreadConstraints: uniformidad por zonas.
• LimitRange/ResourceQuota: protección contra los deployas «borrachos».

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec:
scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: api-gw}
minReplicas: 8 maxReplicas: 200 metrics:
- type: Pods pods:
metric:
name: rps_per_pod target:
type: AverageValue averageValue: "120"
- type: Pods pods:
metric:
name: p99_latency_ms target:
type: AverageValue averageValue: "280"
behavior:
scaleUp:
stabilizationWindowSeconds: 90 scaleDown:
stabilizationWindowSeconds: 300

• «Pause & Rollback» si con el canario p99> 1. 3 × baseline 10 minutos.
• «Freeze scale-down» en prime time, sólo scale-up.
• «Stop retries» en 'open _ circuit = 1' a lugares estrechos.

6) Multi-región: activo/activo y activo/pasivo

Regiones aisladas por Blast: clústeres independientes, secretos/cuotas locales.
Routing global: latency-/geo-based, health-probes, override manual.

• Caliente: replicación local + eventual (streams).
• Transacciones críticas: consistentes por dominio (ledger/balances).
• Failover playbooks: cambio paso a paso de la fuente, TTL, calentamiento de cachés.
• Reglamento de ejercicios (RD): entrenamiento trimestral con objetivos de RTO/RPO.

7) Patrones de red y servicio

Mesh de servicio: mTLS, retry/breaker, outlier detection, límites de downstream.
eBPF/Observabilidad por L4/L7, límites de conexión, protección head-of-line.
APIs internas para S2S, rate-limit compartido y auditoría.
VPC/subredes por zonas blast, control NAT/Egress, peering con vendedores.

8) Rendimiento: pruebas y pruebas

Load & stress en el perfil prime time + worst-case.
Soak (duradero) - fugas de memoria/descriptores, crecimiento latency.
Chaos/game-days: caída del bróker/proveedor/zona, «proveedor lento».
Regresión de la perfección en CI: conjunto de guiones de referencia y gates automáticos.

9) Datos y almacenamiento: estrategias de crecimiento

Crecimiento vertical hasta el «techo» → horizontal/sharding.
Lecturas → réplicas/caché; registros → batch/asinchron/registro.
Migraciones de esquemas: expand → migrate → contract, sin bloqueos globales.
Archivado: lotes fríos en almacenamiento barato + on-demand re-hidratación.
Búsqueda: índices individuales (OpenSearch/Solr) con pipeline de actualizaciones incrementales.

10) Gestión de proveedores y cuotas

Tarjeta de cuotas (TPS, ventanas, costo); alertas 'usage _ ratio> 0. 9`.
Routing a costo/calidad (smart routing).
Los acuerdos de OLA ↔ SLO y el proceso de aumento de cuotas.
Grupo de alternativas y conmutación «caliente».

11) Observabilidad y señales de zoom

• Capacity headroom по слоям; `queue_lag/backlog growth`; `kafka ISR`; `db connections`/`repl lag`; `redis evictions`; `open_circuit`/`retry_rate`; `quota_usage`.
• Métricas de negocio: tasa de éxito/conversión de depósito, tiempo de lanzamiento del juego.
• Costo: costo/RPS, costo/1k calls.

• Capacity Overview (headroom, top risks, burn-rate SLO).
• Stream & Queue Panel (lag/backlog, consumer saturation).
• DB & Cache (p99, connects, hit/evictions).
• Providers & Quotas (TPS, timeouts, costo, conmutación).
• Cambio Seguridad (antes/después del lanzamiento, canario, autogates).

ALERT HeadroomLowAPI
IF capacity_headroom{layer="api"} < 0. 15 FOR 10m

ALERT KafkaBacklogAtRisk
IF (consumer_lag > 5e6 AND rate(consumer_lag[5m]) > 5e4) AND (hpa_desired == hpa_max) FOR 10m

ALERT DBConnectionsNearMax
IF active_conns / max_conns > 0. 85 FOR 5m

ALERT ProviderQuota90
IF usage_quota_ratio > 0. 9 FOR 5m

12) FinOps: escalar rentablemente

Ratios de la eficacia: coste/RPS, coste/depósito, coste/1k de los acontecimientos.
Right-sizing: VPA/recomendaciones, informes sobre «over-provisioned».
Spot/Preemptible para no crítico; Reserved/Committed para carga base.
Egress-presupuesto y almacenamiento en caché, CDN/edge-offload.
Recopilación y archivo de registros por nivel de valor (hot vs cold).
Cuotas de advertencia (soft-cap) y tickets automáticos para la expansión.

13) Procesos y personas

Gestión de cambios: canarios, fichflags, paradas en regresiones.
Incidente-preparación: runbook 'y «dónde agregar capacidad», «cómo cambiar de región».
Planificación de picos: calendario de partidos/torneos/campañas y ventanas de proveedores.
Juegos regulares y ejercicios de RD.
Matriz de posesión: quién puede «cosechar el botón» en el Feilover/aumento de cuotas.

14) Hojas de comprobación de implementación

• Mapa de rutas y límites críticos (por capas), objetivo de la sala de cabecera ≥ 30%.
• HPA por métricas de negocio + Cluster Autoscaler; PDB/SpreadConstraints.
• Colas en vías calientes, idempotency-keys, outbox.
• Cachi: objetivos de hit ≥ 90%, políticas de evictions, índices clave.
• DB: réplicas read, grupos de connects, plan de charding.
• Proveedores: multi-vendedor, cuotas, rompedores/retiros.
• Dashboards «Capacity/Stream/DB/Providers», alertas del § 11.
• Canario y autogates «antes/después del lanzamiento».
• DR-playbook y un entrenamiento parcial de Feilover.

• Calentamiento de cachés, pre-skale HPA/ASG, réplicas warm-standby.
• Aumentar las cuotas de los proveedores, habilitar el enrutamiento inteligente.
• Activar el modo de supresión nocturna para alertas no críticas.
• El «modo seguro» de fichflag está listo para su encendido instantáneo.

15) Anti-patrones

Actualización vertical «a tope» en lugar de horizontal.
Grupo común de hilos/conexiones en todos los hilos (head-of-line).
Retiros en los timautas de los cuellos de botella, ausencia de jitter → tormenta.
No hay histéresis en las alertas y los políticos de escala → «aserrar».
Una única BD global sin charding y localización de datos.
Fe ciega en el SDK del vendedor sin control de taimautas/retraídas/observabilidad.
Ausencia de ejercicios de DR: Feilover «sólo en papel».

16) KPI de escalabilidad

Cumplimiento de SLO en el pico (p95/p99, tasa de éxito).
Headroom por capas en prime time.
MTTS (Mean Time To Scale) - antes de que aparezcan recursos adicionales.
Backlog/Lag Resolution Time - Tiempo de agarre de las colas después del pico.
Change Failure Rate para un período de crecimiento activo.
Costo/RPS y ahorros en caché/CDN/edge-offload.
Lectura DR: RTO/RPO en ejercicios.

17) Ejemplos de plantillas «rápidas»

partitions(topic="bets") = ceil(peak_msgs_per_sec / target_msgs_per_partition)
consumers = min(partitions, max_pods); rebalance_on: skew > 1. 5x scale_up_if: lag > 5e5 && rate(lag[5m]) > 5e4

max_connections = poolers pool_size 1. 3 read_routing: primary (write), replicas (read majority)
shard_key: tenant_id or region_id

maxmemory-policy: allkeys-lfu cluster-replicas: 1 evict-alert: rate(evictions[5m]) > 0 && used_mem/limit > 0. 8

guardrails:
- metric: api_p99_ms, threshold: 1. 3 baseline_1d, window: 10m, action: pause_and_rollback
- metric: error_rate, threshold: 2 baseline_1d, window: 5m, action: pause max_step: 10%
step_interval: 15m

18) FAQ

P: ¿Qué escalar primero?
R: Cuellos de botella según dashboards: cola/caché/lectura DB. Vías calientes (depósito/apuesta/lanzamiento del juego) - prioritario.

P: ¿Cómo entender que la escala automática «empeora»?
R: Vea la correlación: scale- up↑, y p99/errores no mejoran - tal vez usted está «escalando el problema» (downstream/cuota estrecha). Habilite los rompecabezas/degradación.

P: ¿Necesita un segundo proveedor siempre?
R: Para los caminos críticos - sí. De lo contrario, al menos «modo seguro» con script simplificado y caché.

Q: Active-active или active-passive?
R: Si los requisitos de RTO son bajos y hay muchos jugadores regionales - active-active. De lo contrario, comience con active-passive con el failover de trabajo.