Zonas de disponibilidad y regiones cruzadas

1) Términos y objetivos

Zona de disponibilidad (AZ) - Centro de datos aislado dentro de la región (capacidad/red nativa).
La región es un grupo de AZ con geografía general y retrasos.

• RTO (Recovery Time Objective) - ¿Cuánto tiempo puede no prestar el servicio.
• RPO (Recovery Point Objective): qué cantidad de datos se puede perder.

Normalmente: dentro de la región, apuntamos a RTO ≤ 5-15 min, RPO ~ 0-1 min, interregional - RTO ≤ 1 h, RPO ≤ 5 min (depende del producto y el presupuesto).

2) Modelos arquitectónicos

2. 1 Dentro de la región (multi-AZ)

Capa sin estado: distribuida por AZ; equilibrio - L4/L7 con health-checks.
Capa de estado: clústeres con replicación sincrónica (o quórum) entre AZ.
Caché/colas: clúster, con charding por AZ y failover automático.

2. 2 Interregional (multi-región)

Active-Active: ambas regiones reciben tráfico.

latencia mínima para los usuarios, recuperación rápida, − complejidad de consistencia y conflicto.
Active-Passive (hot/warm): la región principal sirve, la segunda está en espera caliente/caliente.

datos más simples, más baratos, − RTO arriba.
Pilot-Light: mínima «luz» (los datos se sincronizan, los cálculos se despliegan en caso de accidente).
DR-backup: sólo los backups y el escenario de recuperación (el más barato y el más lento).

3) Datos y consistencia

3. 1 Bases de datos

Quórum sincrónico (RPO≈0, ↑latentnost): PostgreSQL con standbys sincrónicos dentro de la región; BD distribuidas (CockroachDB/Cassandra) con quórum local (Local Quorum) y equilibrio AZ.
Interregional asíncrona (RPO> 0, ↓latentnost): replicación lógica de Postgres/MySQL; «global tables» в KV/NoSQL; CDC→strim a otra región.
Entradas en conflicto: para active-active, utilice CRDT/versioning o estrategia de «fuente de verdad» (leader-region per key/tenant).

3. 2 Sorteo de eventos y colas

Colas/streams (tipo Kafka/Pulsar/SQS): mirror-topics o replicadores transversales regionales; la clave es la idempotencia de los consumers y del dedoup en las llaves.
Webhooks y socios externos: firmar, tener replay, almacenar offset/checkpoints en ambas zonas.

3. 3 Caché

Caché local por región (write-through/refresh-ahead); caché compartido global sólo para KV duraderos (de lo contrario split-brain). Invalidez por eventos (pub/sub), TTL es conservadora.

4) Tráfico global y bucle de red

GSLB/DNS: Geo- J Latency-based routing, health-checks, «traffic-weights» para Canarias y accidentes.
Anycast/Edge: acercamos la entrada al usuario, a continuación, a la región saludable más cercana.
Políticas fallidas: pools regionales de upstream's, prohibición de 0-RTT en rutas críticas, tiempos bajos a dependencias interregionales.
Políticas de retroceso: retroceso exponencial + jitter, restricción total-deadline, PUT/POST idempotente con 'Idempotency-Key'.

5) Kubernetes y servicio de mesh

5. 1 Multi-AZ en un solo clúster

topology spread constraints по `topology. kubernetes. io/zone`.
PodDisruptionBudget и priority classes.
NodeAffinity/Anti-Affinity - evitar la co-ubicación de réplicas.
Zonas de almacenamiento: fotovoltaicos con replicación por AZ o sistemas de volumen distribuidos.

5. 2 Multi-region (multi-cluster)

Clústeres separados por región + GitOps (Argo CD/Flux) para sincronización declarativa.
Mesh de servicio (Istio/Linkerd): locality-aware load-balance y failover entre regiones; mTLS, identidad común.
Traffic-shifting: por etapas 1%→10%→50% a la nueva región; pluma «poner 0%» instantáneamente.

6) Selección de RTO/RPO y referencia a patrones

7) Pruebas de tolerancia a fallas (DR)

GameDays: escenario trimestral a gran escala «extinguido región/AZ».
Inyección Chaos: latencia de red, pérdida de paquetes, desconexión del bróker/base en un único AZ.
RTO/RPO reales: medir el tiempo de conmutación y la pérdida de datos, publicar el informe.
Runbooks: instrucciones paso a paso y «botones rojos» para cambiar (DNS weights, feature-flags, desactivar el fich pesado).

8) Observabilidad y gestión

Cortes de métricas por región/AZ/tenant; p95/p99 de latencia a lo largo de las rutas.
SLO y Error Budgets por región y por grupo global.
Alertas: la degradación de una región no debe «silenciar» la paginación si la segunda lleva el tráfico normalmente.
Трейсы: baggage `region`, `az`, `failover=true/false`; informes «cuántas solicitudes se han ido a failover».

9) Seguridad y cumplimiento

Residencia de datos: vincular los datos PII/de pago a determinadas regiones (jurisdicción).
Secretos: KMS/Smart-HSM con claves regionales cruzadas y rotación; separe los materiales de las llaves por región.
mTLS y confianza mutua entre regiones; limite el egreso regional cruzado a la ACL.

10) Costo y ahorro

Edge caché + SWR - Reducción de la egresa interregional.
Diferentes clases de almacenamiento (hot/warm/cold) y downsampling métricas/logs.
Perfiles de escala automática por región (mínimo nocturno).
Identidad de imagen + configuración diferenciada a través de variables de entorno/valores de Helm.

11) Antipattern

Un asistente Stateful para todo el sistema; split-brain sin quórum.
Escritura sincrónica interregional en un solo RDBMS (latencia inasumible).
Caché global con fuerte consistencia sin CRDT → congestión y «fantasmas».
Retraídas sin idempotencia → duplicados de transacciones/pagos.
Un solo SLO «global» - esconde el fracaso de una región.
No hay ejercicios regulares de RD: los planes son inoperantes en combate.

12) Especificidad de iGaming/finanzas

Los proveedores de pagos/CCA se seleccionan a nivel regional; hacer smart-routing por PSP con señales de salud, failover en respaldo.
Jurisdicción: custodia de los registros PII y de las transacciones nacionales y regionales; región cruzada - sólo agregados/anónimos.
Límites/juego responsable: reglas y horas locales - no replique «de frente» entre regiones, use consistencia de eventos.
Bonificaciones/balance: llaves idempotentes y «fuente de la verdad» per tenant/region; reconcile-joba después de DR.

13) Mini recetas (pseudoconfigs)

13. 1 Envoy locality-aware + failover

yaml load_assignment:
endpoints:
- locality: { region: eu, zone: eu-a }
lb_endpoints: [{ endpoint: { address:... } }]
- locality: { region: eu, zone: eu-b }
lb_endpoints: [{ endpoint: { address:... } }]
- locality: { region: us, zone: us-a } # failover target lb_endpoints: [{ endpoint: { address:... } }]
common_lb_config:
zone_aware_lb_config: {}
locality_weighted_lb_config: {}
outlier_detection:
consecutive_5xx: 5 base_ejection_time: 30s

13. 2 Kubernetes topology spread

yaml spec:
topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology. kubernetes. io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }

13. 3 DNS peso Feilover (idea)

'weight (eu) = 90', 'weight (us) = 10' → al degradarse 'eu' automáticamente el cambio a 'us'. Cheques de salud y TTL reducidos (pero no demasiado agresivos, 30-120 s).

14) Lista de comprobación prod

• Se define el servicio RTO/RPO per y se negocia con el negocio.
• Stateless se distribuye por AZ; stateful tiene quórum/replicación y un modelo de consistencia comprensible.
• Replicación interregional (asinchron/CDC), pruebas de conflicto/deduplicador.
• Los GSLB/Anycast están configurados, los cheques de salud y los weights son automatizables.
• Kubernetes: topology-spread, PDB, anti-affinity; multi-cluster GitOps.
• Retrés con jitter, idempotencia en escritura; los timautas cortos son interregionales.
• Ejercicios de RD medidos por RTO/RPO reales; runbook actual.
• Observabilidad por región/AZ, SLO y burn-rate en los cortes, las alertas no «silencian» el funcionamiento normal.
• Data residency/secretos/claves se ajustan a la regulación.
• Economía: egresos, almacenamiento, perfiles de autocaravana bajo control.

15) TL; DR

Construye multi-AZ como capa base, multi-región - como seguro empresarial. Seleccione un patrón (active-active/standby) bajo RTO/RPO y costo, replique los datos conscientemente (quórum/CDC/CRDT), administre el tráfico global a través de GSLB/Anycast y locality Equilibrio de aware. Son obligatorias: idempotencia, tiempos cortos, ejercicios regulares de DR, SLO/métricas en los cortes de la región/AZ. Para iGaming/finanzas, agregue PSP/KYC regionales, requisitos de datos y SLO separados por jurisdicción.