Planteamiento y alcance
Eres responsable de un SaaS global donde una falla en la base de datos, en la cola o en el despliegue de un clúster puede afectar a todos los inquilinos. Diseña una arquitectura basada en celdas: cada celda es una copia completa del sistema operable de manera independiente que atiende a un conjunto fijo de inquilinos, y una capa de entrada enruta las solicitudes a la celda de destino mediante un mapeo estable.
Cubre la partición de inquilinos, el directorio de enrutamiento, los límites de cómputo y datos dentro de una celda, los reportes entre celdas, los lanzamientos, la migración, la capacidad y la recuperación ante desastres. AWS describe las celdas como réplicas independientes y almacena el mapeo de usuario a celda en un almacenamiento de alta disponibilidad; su guía sobre mamparos (bulkheads) describe el enrutamiento mediante una clave de partición detrás de un único endpoint.
Qué evalúa el entrevistador
- Si defines primero el alcance de la falla, la consistencia del inquilino y la degradación aceptable.
- Si una celda es un dominio de falla real en lugar de servicios sin estado duplicados.
- Si identificas los riesgos de enrutamiento, plano de control, dependencias compartidas y consultas entre celdas.
- Si las nuevas celdas, el rebalanceo y la migración de inquilinos tienen pasos reversibles.
- Si las métricas de capacidad, errores y dependencias a nivel de celda demuestran la afirmación sobre el radio de impacto.
Las referencias de entrevistas de diseño de sistemas tratan la arquitectura basada en celdas como un patrón de aislamiento para sistemas muy grandes. Una respuesta sólida explica cuándo el beneficio de confiabilidad justifica la infraestructura y las operaciones duplicadas; una celda no es un sinónimo de microservicio.
Preguntas de aclaración antes de responder
- ¿El alcance objetivo de la falla es un inquilino, una celda, una Zona de Disponibilidad o una región?
- ¿Pueden los inquilinos compartir datos, búsquedas globales o agregaciones entre inquilinos?
- ¿Qué operaciones requieren linearizabilidad y qué reportes pueden demorarse o ser eventualmente consistentes?
- ¿La migración puede ser brevemente de solo lectura? ¿Existen restricciones de residencia de datos?
- ¿Cuáles son los objetivos de disponibilidad, el número de inquilinos, el crecimiento, la capacidad por celda y la frecuencia de lanzamientos?
Estructura de respuesta en 30 segundos
Mapearía una clave de inquilino estable a una celda fija. Cada celda posee cómputo, colas, cachés y almacenamiento de datos primario; el plano de control global posee únicamente versiones, capacidad y mapeos. Un enrutador de entrada lee un directorio de alta disponibilidad y aísla únicamente la celda fallida. Los reportes entre celdas utilizan agregación asíncrona para que las consultas no recreen una base de datos compartida. La creación, migración y lanzamiento de celdas utilizan pasos pequeños, observables y reversibles, con SLOs a nivel de celda que demuestran el límite de falla.
Respuesta profunda paso a paso
Paso 1: Definir los límites de la celda y las suposiciones de falla
Define una celda como una copia completa que se puede desplegar y recuperar de forma independiente: API, workers, caché, base de datos, prefijo de almacenamiento de objetos y monitoreo. Los servicios compartidos de identidad, facturación o configuración necesitan un presupuesto de fallas explícito. Si un plano de control compartido bloquea cada celda cuando no está disponible, el plano de datos no está completamente aislado.
Paso 2: Elegir la clave de partición y el directorio de enrutamiento
Usa tenant_id como una clave de partición estable. El directorio almacena el mapeo de inquilino a celda, la versión, el estado de migración y la capacidad. El enrutador lee primero una caché local y se actualiza desde un directorio de alta disponibilidad; los números de versión y los arrendamientos (leases) evitan que las rutas antiguas escriban en dos celdas durante la migración. Los clientes ven un único nombre de host mientras el enrutador gestiona los límites de reintentos.
Paso 3: Construir el plano de datos dentro de la celda
Cada celda tiene su propia base de datos primaria y cola de mensajes; los datos del inquilino no se escriben sincrónicamente entre celdas. Las réplicas, cachés y almacenamiento de objetos llevan la identidad de la celda, y las copias de seguridad retienen esos metadatos. La configuración global utiliza instantáneas de solo lectura o despliegues versionados en lugar de enviar tráfico activo a una sola base de datos global.
Paso 4: Gestionar las consultas entre celdas
Cada celda emite un flujo de cambios para construir tablas agregadas consumidas por una capa de analítica global. Los reportes incluyen la marca de tiempo de los datos y marcadores de celdas faltantes en lugar de reclamar completitud en tiempo real. Las operaciones fuertemente consistentes entre inquilinos deben acotarse, hacerse asíncronas o aceptar explícitamente un dominio de falla compartido más grande; evita el commit en dos fases en la ruta crítica de la solicitud.
Paso 5: Diseñar rutas de falla y degradación
Las verificaciones de estado cubren las dependencias dentro de la celda, la accesibilidad de las rutas y la corrección del negocio. Cuando una celda falla, el directorio la marca como en drenaje (draining) y detiene las nuevas solicitudes; las cachés de lectura o el trabajo asíncrono pueden degradarse cuando el producto lo permita. No muevas inquilinos a una celda arbitraria hasta que se demuestren los límites de replicación, idempotencia y autorización, o la conmutación por error puede crear escrituras duplicadas.
Paso 6: Agregar celdas y rebalancear la capacidad
Crea una celda vacía a partir de la plantilla de infraestructura, ejecuta tráfico sintético y lecturas en la sombra (shadow reads), y luego admite un conjunto pequeño de inquilinos. Las señales de capacidad incluyen CPU, conexiones de base de datos, retraso en colas, crecimiento del almacenamiento y costo por inquilino. El rebalanceo congela una versión de mapeo, copia y verifica datos, realiza una breve transferencia de escritura y observa las celdas antiguas y nuevas; ante una falla, revierte el mapeo en lugar de eliminar los datos antiguos.
Paso 7: Gobernar lanzamientos y versiones
Lanza el plano de control, la plantilla de la celda y la versión de negocio por separado. Realiza despliegues canary en una celda y luego expande celda por celda. Mantén una ventana de compatibilidad para que una nueva versión no pueda escribir campos que una versión anterior no pueda leer. Haz que la distribución de versiones y los errores sean visibles por celda; los promedios globales no pueden ocultar una versión defectuosa.
Paso 8: Verificar el radio de impacto y el costo operativo
Inyecta fallas de base de datos, colas, directorio de enrutamiento y despliegues en una celda y confirma que solo los inquilinos esperados se vean afectados. Rastrea la disponibilidad de la celda, el presupuesto de errores, la proporción de solicitudes entre celdas, el tiempo de reversión de migración, la dependencia del plano de control compartido y la capacidad de reserva. Si las celdas son muy pocas para aislar fallas o las operaciones duplicadas cuestan más que la ganancia en confiabilidad, elige un diseño de partición o mamparo más simple.
Respuesta modelo
Mapearía tenant_id a una celda fija. Cada celda ejecuta de forma independiente API, colas, cachés y almacenamiento primario; el plano de control posee únicamente versiones, capacidad y mapeos. Un enrutador bajo un solo nombre de host lee un directorio versionado y de alta disponibilidad, y una celda fallida entra en drenaje en lugar de aceptar escrituras no verificadas en otra parte. Los reportes entre celdas son asíncronos mediante flujos de cambios. La migración utiliza copia, verificación, una breve transferencia de control y un mapeo reversible. Demostraría la afirmación sobre el radio de impacto con SLOs por celda, proporción de dependencias compartidas, tiempo de reversión y simulacros de fallas; si los costos de aislamiento superan sus beneficios, utilizaría un mamparo más simple.
Errores comunes
- Duplicar solo servicios sin estado → la base de datos compartida sigue siendo un punto único de falla → define el límite de datos y colas de cada celda.
- Mover inquilinos al azar durante una falla → escrituras duplicadas o discrepancia de autorizaciones → demuestra primero la replicación, idempotencia y versiones de ruta.
- Agregar entre celdas en la ruta de solicitud → genera un nuevo dominio de falla global → utiliza agregación asíncrona con marcadores de marca de tiempo de datos.
- Usar únicamente verificaciones de estado globales → una celda defectuosa queda oculta por los promedios → registra los SLOs a nivel de celda y la distribución de versiones.
- Cambiar la ruta directamente durante la migración → las escrituras antiguas y nuevas se superponen → utiliza versiones de mapeo, verificación de copia y reversión.
- Dar a cada dependencia su propia celda → costos y operaciones descontrolados → cuantifica primero el radio de impacto y el beneficio de capacidad.
Preguntas de seguimiento y respuestas
¿Qué pasa si falla el directorio de enrutamiento?
Mantén cachés locales versionadas e instantáneas de solo lectura, restringe los cambios de mapeo y permite que los inquilinos existentes continúen en sus celdas originales. No rebalancees de forma generalizada hasta que el directorio se recupere.
¿Qué pasa si un reporte de administración debe ser en tiempo real entre celdas?
Aclara el retraso permitido y la semántica de datos faltantes. La consistencia fuerte puede requerir acotar la operación o aceptar un dominio de falla compartido más grande; los reportes normales deben usar agregados asíncronos con marcas de tiempo.
¿Cómo se migra un inquilino cuando una celda está llena?
Copia y verifica los datos, publica una nueva versión de mapeo, coordina una breve transferencia de escritura y escala el tráfico gradualmente. Mantén la celda anterior hasta que se demuestre la consistencia; revierte el mapeo si no es así.
¿Es seguro desplegar una versión en solo algunas celdas?
Sí, con esquemas compatibles, observabilidad de versiones y un orden de despliegue explícito. La tasa de éxito global no puede sustituir los presupuestos de error por celda.
¿Cómo demuestras que la falla no se propagó?
Realiza simulacros de fallas de base de datos, colas, enrutamiento y despliegues dentro de una celda. Registra los inquilinos afectados, las solicitudes entre celdas, el tiempo de recuperación y las llamadas a dependencias compartidas.
¿Cuándo no deberías usar una arquitectura basada en celdas?
Cuando la escala de inquilinos y el costo de fallas son bajos, o la consistencia fuerte entre inquilinos es predominante, los recursos duplicados y la complejidad de la migración pueden no compensar la inversión.
¿Cómo pueden las celdas compartir identidad y facturación?
Mantén los servicios compartidos en un plano de control de baja tasa de llamadas, almacena en caché resultados de solo lectura y define modos de degradación. Las escrituras de facturación necesitan claves de idempotencia y compensación para que una falla en el servicio compartido no se extienda a todos los planos de datos.