Arquitectura de referencia: multirregión / global
Cuando los usuarios están distribuidos geográficamente o se requiere resiliencia ante un desastre regional, los datos se reparten entre varias regiones. Este árbol recorre paso a paso la localidad de lectura (una réplica de lectura en cada región), la topología de escritura (single-leader vs multi-leader vs quórum), la residencia de datos/cumplimiento normativo (GDPR), la resolución de conflictos y los compromisos entre RPO/RTO y latencia. La verdad básica: por las leyes de la física, la baja latencia, la consistencia fuerte y las escrituras multirregión no pueden lograrse plenamente a la vez; es obligatorio un compromiso deliberado.
¿Por qué opta por multirregión: localidad de lectura, escrituras/resiliencia o cumplimiento normativo?
Una arquitectura multirregión es costosa y compleja; aclare la motivación. ¿Quiere baja latencia de lectura para usuarios lejanos, escrituras entre regiones/resiliencia ante desastres, o el verdadero requisito es que los datos permanezcan en un país concreto (residencia legal)?
- Lecturas rápidas para usuarios lejanos; las escrituras pueden quedarse en una región
- Se requieren escrituras entre regiones / resiliencia ante la pérdida de una región
- Los datos deben permanecer legalmente en un país/región concretos
¿Cuál debe ser la topología de escritura: single-leader, multi-leader o quórum?
Para las escrituras entre regiones, la decisión clave es el modelo de liderazgo. ¿Todas las escrituras van a una sola región (sencillo, consistente, pero las escrituras remotas son lentas), puede escribir cada región (baja latencia de escritura pero con conflictos), o se acepta una escritura con la confirmación de la mayoría de las regiones (quórum: consistente pero con latencia añadida)?
- Una región escribe, las demás leen (sencillo y consistente)
- Cada región puede escribir localmente (baja latencia de escritura)
- Escribir con confirmación de la mayoría; lo primero es la consistencia
Recomendación: una réplica de lectura por región (localidad de lectura)
Las escrituras permanecen en una única región primaria mientras coloca en cada región de usuarios una réplica de lectura alimentada desde ella. Los usuarios leen de la réplica más cercana y la latencia de lectura baja; como las escrituras siguen yendo a un único centro, el modelo de consistencia sigue siendo sencillo.
Recomendación: escrituras single-leader
Todas las escrituras van a una única región líder; las demás regiones son réplicas de lectura alimentadas de forma asíncrona desde ese líder. Es el modelo más sencillo y con consistencia más fuerte; no hay conflictos porque existe un único punto de escritura. El precio es una alta latencia de escritura desde regiones remotas.
Recomendación: escrituras multi-leader + resolución de conflictos
Como cada región puede escribir localmente, la latencia de escritura es baja y, aunque una región quede aislada, las demás siguen escribiendo. El precio es alto: dos regiones pueden actualizar el mismo registro de forma distinta, y debe diseñar la resolución de conflictos.
Recomendación: escrituras basadas en quórum (confirmación de la mayoría)
Una escritura se acepta cuando la confirma una mayoría (quórum) de regiones/réplicas; cuando las lecturas también van a una mayoría, se garantiza el valor más reciente. Es resiliente ante la pérdida de una región y tiene consistencia fuerte; el precio es la latencia de que cada escritura llegue a una mayoría.
Recomendación: residencia de datos / cumplimiento normativo (GDPR)
Algunos datos (personales, sanitarios, financieros) deben permanecer legalmente dentro de las fronteras de un país/región concretos (p. ej. GDPR). En este caso, la arquitectura no se diseña en torno a «copiar en todas partes», sino para que los datos queden anclados geográficamente.