Consigna y caso de uso
Un servicio global ya asigna inquilinos a múltiples celdas; aun así, un mal despliegue, la falla de una dependencia compartida o un evento de capacidad provocan una interrupción amplia. Audite la arquitectura actual, identifique las rutas que propagan el impacto entre celdas y diseñe verificaciones repetibles de inyección de fallas y recuperación que demuestren que cada celda es un límite real de aislamiento.
Qué evalúa el entrevistador
- Si define una celda como una réplica completa que puede ejecutarse, escalarse y revertirse de forma independiente.
- Si puede razonar sobre el radio de impacto, los mapas de enrutamiento y la asignación consistente de nuevos usuarios.
- Si maneja planos de control compartidos, datos entre celdas, asimetría de capacidad y migración de inquilinos de alto tráfico (hot tenants).
- Si convierte los despliegues progresivos, las compuertas de métricas y los simulacros de recuperación en operaciones concretas.
Preguntas para aclarar antes de responder
- ¿La clave de aislamiento es un usuario, inquilino, región o partición de negocio, y se permite el acceso entre regiones?
- ¿Qué datos deben ser globalmente consistentes y cuáles pueden ser eventualmente consistentes dentro de una celda?
- ¿El objetivo es limitar el impacto de los despliegues, sobrevivir a un desastre regional o ambos?
- ¿La carga es predecible, puede trasladarse un inquilino de alto tráfico y cómo se mantiene la idempotencia durante la migración?
Estructura de respuesta de 30 segundos
Primero mapearía las dependencias de cómputo, caché, colas, datos y plano de control de cada celda y marcaría cada ruta compartida. Luego definiría invariantes de aislamiento para el enrutamiento, la capacidad, los despliegues y el trabajo entre celdas. Inyectaría sobrecarga en una celda, un despliegue defectuoso, una interrupción en la dependencia de datos y la pérdida del plano de control, verificando que la tasa de errores y la latencia de las celdas en buen estado se mantengan dentro de los límites. Cualquier dependencia que propague impacto debe particionarse, limitarse por cuotas o respaldarse con una alternativa de instantánea local. El tiempo de recuperación, el porcentaje de inquilinos afectados y la evidencia de los simulacros determinan si el aislamiento es real.
Análisis detallado paso a paso
1. El límite de la celda
Una celda es una unidad del sistema que se puede desplegar, escalar y recuperar de forma independiente; por lo general contiene instancias de servicio, cachés, colas y una partición de datos dedicada. Los servicios compartidos de DNS, identidad o configuración deben mantener privilegios mínimos y un acoplamiento débil, con un comportamiento de degradación definido.
2. Enrutamiento y mapeo
La capa de enrutamiento busca en un mapa por clave de usuario o de inquilino y reenvía la solicitud a una celda de destino. El mapa necesita una versión, suma de comprobación y política de expiración. Durante una migración, escriba primero el nuevo mapa y drene las solicitudes antiguas para que una entidad no escriba en dos celdas a la vez.
3. Aislamiento de datos
Cada celda posee un límite de escritura local; las consultas entre celdas prefieren proyecciones de lectura replicadas de forma asíncrona. La unicidad global corresponde a un coordinador dedicado o se convierte en unicidad local por partición con reconciliación eventual, en lugar de concentrar cada escritura en un único punto compartido.
4. Capacidad y puntos calientes
Establezca cuotas de solicitudes, colas, conexiones a bases de datos y almacenamiento por celda para acotar el radio de impacto máximo. Monitoree la distribución de inquilinos y las marcas de nivel de recursos. Un inquilino de alto tráfico puede moverse a una celda inactiva, pero la migración necesita lectura dual, escritura única y eventos reproducibles.
5. Riesgo del plano de control compartido
El plano de control gestiona mapas, versiones y orquestación; no debería transportar todos los datos de negocio. Durante una interrupción del plano de control, los enrutadores pueden prestar servicio a partir de una instantánea local con un TTL. Tras la expiración, permita solo lecturas seguras o devuelva un error reintentable.
6. Despliegue y reversión
Ejecute la nueva versión en una celda y compárela con las celdas de referencia en tasa de errores, latencia de cola, saturación de recursos y métricas de negocio. Expanda en lotes tras superar las compuertas de control. Cualquier regresión pausa la expansión y revierte esa celda sin degradar las celdas en buen estado.
7. Operaciones entre celdas
Los informes entre celdas, los trabajos por lotes y las migraciones de cuentas se ejecutan mediante un orquestador con claves de idempotencia, concesiones (leases) y puntos de control de progreso. En caso de falla, reintente solo las particiones incompletas y exponga la finalización parcial explícitamente a los llamadores.
8. Recuperación ante desastres y simulacros
Haga copias de seguridad de los datos y la configuración de cada celda, con objetivos de punto de recuperación y tiempo de recuperación definidos. Realice simulacros de aislamiento de una sola celda, pérdida del plano de control, falla regional y corrupción del mapeo para verificar la transferencia de tráfico, la restauración de datos y los scripts de reversión en lugar de confiar en una redundancia teórica.
Respuesta de muestra de alta calidad
“No asumiría el aislamiento simplemente porque el servicio esté desplegado en varias celdas. Rastrearía una solicitud de inquilino a través de bases de datos, colas, cachés, identidad, configuración, enrutamiento y el pipeline de despliegue para identificar dominios de falla compartidos. Luego definiría tres invariantes: agotar una celda no puede consumir los recursos de otra, una compilación defectuosa solo puede entrar en un lote de despliegue, y el plano de datos puede continuar a partir de una instantánea de enrutamiento local durante una interrupción breve del plano de control.
En un entorno de staging o en un simulacro de producción estrictamente aislado, inyectaría sobrecarga en una celda, pérdida de base de datos, mala configuración y pérdida del directorio de enrutamiento. Las celdas en buen estado deben permanecer dentro de las compuertas de tasa de errores, latencia P99 y saturación. Cualquier dependencia compartida que propague fallas recibe particionamiento, cuotas por celda o una alternativa de instantánea local versionada. Las verificaciones de recuperación cubren el aislamiento del tráfico, la integridad de los datos y la reversión de mapeos. Haría que el porcentaje de inquilinos afectados, el tiempo de recuperación y la salud entre celdas fueran la evidencia de despliegue, para que el equipo demuestre el aislamiento repetidamente en lugar de confiar en el diagrama de arquitectura”.
Errores comunes
- Replicar el cómputo sin estado mientras se sigue compartiendo una base de datos, cola o grupo de conexiones.
- Comprobar si la celda que falló se recupera sin verificar la tasa de errores y la latencia de cola de las celdas en buen estado.
- Usar enrutamiento aleatorio en lugar de un mapeo de inquilinos estable, provocando escrituras entre celdas.
- Probar la pérdida de infraestructura pero omitir despliegues defectuosos, inquilinos de alto tráfico y fallas del plano de control.
Preguntas de seguimiento y respuestas
¿Cómo sabe si un plano de control compartido rompe el aislamiento?
Desconéctelo durante un simulacro y verifique que los enrutadores puedan prestar servicio a partir de mapeos locales versionados con un TTL. Después de que la instantánea expire, el sistema necesita un estado de degradación segura explícito.
¿Qué debería medir una compuerta de aceptación de aislamiento?
Establezca límites para la tasa de errores, la latencia P99, la saturación y el porcentaje de inquilinos afectados en las celdas en buen estado, y registre el tiempo de recuperación. La recuperación de la celda fallida por sí sola no demuestra el aislamiento.
¿Tener más celdas siempre significa un mejor aislamiento?
No. Las celdas más pequeñas reducen el radio de impacto teórico, pero aumentan la fragmentación de capacidad, los lotes de despliegue y el costo operativo entre celdas. Deduzca la cantidad a partir del porcentaje objetivo de inquilinos afectados, la capacidad de la celda y el costo operativo sostenible.
¿Pueden los reportes entre celdas recrear una falla compartida?
Sí. Los informes deben leer proyecciones asíncronas con cuotas y degradación independientes. Las solicitudes en línea no deben propagarse de forma sincrónica a todas las celdas.