Multi-region (en planificación Q4 2026)

Estado al 2026-04-26: multi-region nativo no está disponible. La función entró al roadmap para el cuarto trimestre de 2026. Esta página existe para ayudarte a prepararte — y mostrar cómo convivir bien sin ello hasta entonces.

Por qué importa multi-region

Tres motivos principales:

1. Latencia regional. Servir a un usuario en Recife desde Virginia agrega 130ms ida-y-vuelta antes incluso de que la aplicación responda. Para algunos productos, es tolerable. Para otros, es la diferencia entre vender y perder venta.
2. Disaster recovery. Un datacenter entero puede caer. Un proveedor entero puede quedar fuera por horas. Estar presente en otra región te da un plan B real.
3. Compliance y residencia de datos. La LGPD favorece datos de ciudadanos brasileños en territorio nacional. GDPR es aún más explícita en Europa. Para vender en mercados regulados, la región donde vive el dato deja de ser un detalle técnico.

Cómo correr en varias regiones hoy

Sin soporte nativo, el camino actual involucra clusters independientes — uno por región — coordinados por DNS.

Topología típica:

                        Cloudflare DNS
                       (geo steering)
                              │
                ┌─────────────┼─────────────┐
                │             │             │
        cluster-br      cluster-us    cluster-eu
        (São Paulo)    (Virginia)    (Frankfurt)
        4 nós          4 nós         4 nós

Cada cluster:

• Corre independiente. Tiene su propio plano de control.
• Recibe los mismos jobs, configurados por separado.
• Tiene su propio backup, sus propios secretos, sus propias métricas.

El DNS resuelve al usuario al cluster más cercano. Cloudflare Geo Steering o AWS Route 53 con latency-based routing hacen ese trabajo.

Puntos a observar

• Los cambios deben aplicarse en todos los clusters. Vale la pena automatizar — aunque sea con un script que hace heroctl jobs submit en cada cluster.
• Los secretos viven aislados. Actualizar una contraseña en un cluster no la actualiza en los otros.
• La base de datos es problema separado. Réplicas de lectura por región, escritura centralizada, o modelos active-active — elige tu estrategia. No hay magia aquí.

Escenarios comunes

Startup brasileña que quiere expandirse

Topología mínima: un cluster en São Paulo, un cluster en US-East. DNS rutea por proximidad.

Ventaja: el usuario brasileño tiene latencia baja local; el cliente internacional no siente el retraso de cruzar el Atlántico dos veces.

Empresa con clientes en mercados regulados

Cluster BR para cliente brasileño. Cluster EU para cliente europeo. Cluster US para el resto.

Cada cluster queda en jurisdicción apropiada. Los datos no atraviesan fronteras a menos que decidas explícitamente.

Disaster recovery puro

No importa dónde esté el usuario — solo quieres un plan B si el proveedor primario cae.

Cluster activo + cluster pasivo en otra región. DNS apunta al activo. En desastre, cambia el DNS al pasivo. Restauras el snapshot más reciente allí. Tiempo de recuperación: minutos a una hora, dependiendo del tamaño.

Trade-offs honestos

Multi-region no es gratis. Los costos:

• Latencia cross-region. Sincronizar cualquier cosa entre regiones agrega decenas a cientos de milisegundos.
• El tráfico inter-región es caro. La mayoría de las nubes cobra por GB que sale de la región. Multiplica por escala y el número asusta.
• La operación crece. Dos clusters no son dos veces un cluster — son tres veces (porque la coordinación entre ellos es trabajo nuevo).
• Debug se vuelve más difícil. Un problema que aparece en una región y no en la otra exige hipótesis extras.

La regla práctica: solo ve multi-region cuando el costo de no estarlo sea mayor que el costo de estarlo. Latencia mala que está perdiendo cliente. Compliance que está bloqueando contrato. Riesgo de DR que mantiene al equipo despierto de noche. Si nada de eso es verdad, quédate en una región y duerme mejor.

Roadmap

Lo que viene en HeroCtl:

Fechas indicativas. Las cosas cambian.

Cómo prepararse ahora

Aún sin soporte nativo, algunas decisiones facilitan la transición:

• Mantén las definiciones de jobs en archivos versionados. Querrás aplicar los mismos jobs en más de un cluster.
• Centraliza secretos en un vault externo. Vault, AWS Secrets Manager, o similar. Cada cluster los busca de allí.
• Piensa en la base de datos desde ya. Migrar a un modelo regional después es más doloroso que empezar planificado.
• Documenta tu RPO y RTO. Cuántos datos puedes perder. Cuánto puedes estar fuera. Las respuestas guían todas las demás decisiones.

Interés anticipado

Si quieres participar del beta de federación en Q4 2026, escribe a roadmap@heroctl.com con:

• Cuántas regiones operas hoy
• Volumen estimado de jobs
• Restricciones regulatorias relevantes

Seleccionamos un grupo pequeño de partners para el programa anticipado. El feedback en esa fase moldea el producto final.

Próximos pasos

• Backup y restauración — base de cualquier estrategia DR.
• Ingress — DNS y ruteo para múltiples endpoints.
• Troubleshooting — problemas operacionales comunes.