Entrevista de diseño de sistemas: ¿Cómo aislar a los inquilinos ruidosos y programar de manera equitativa?

Consigna y contexto

El núcleo del problema es el aislamiento del rendimiento y la equidad, no simplemente agregar un tenantId. El servicio acepta trabajos de reportes asíncronos que consumen colas, CPU, escaneos de bases de datos, almacenamiento de objetos y ancho de banda de descarga. Una ráfaga de fin de mes hace que algunos inquilinos se vuelvan ruidosos. Comience definiendo los objetivos del servicio y luego explique qué se comparte y qué se aísla.

Asuma que un inquilino solo puede leer sus propios datos, que los reportes pueden completarse de forma asíncrona y que un retraso temporal es preferible a una filtración entre inquilinos. Los inquilinos empresariales pueden tener diferentes planes, regiones y políticas de retención; el cumplimiento normativo, la residencia de datos y la capacidad dedicada son restricciones estrictas que deben aclararse. La equidad no significa un rendimiento idéntico para siempre: las prioridades contractuales y de seguridad pueden tener ponderaciones explícitas y auditables.

Este escenario encaja en entrevistas de backend, plataforma, SRE y diseño de sistemas. AWS presenta el shuffle sharding como un patrón fundamental de aislamiento multi-tenant, mientras que el material público de diseño de sistemas trata el aislamiento de inquilinos, las cuotas y los "vecinos ruidosos" como preocupaciones de diseño habituales. Esta pregunta se centra en la programación y el radio de impacto (blast radius) más que en un conjunto completo de características de SaaS.

Qué evalúan los entrevistadores

Primero, ¿puede identificar todas las superficies de aislamiento? La identidad del inquilino, los trabajos, las colas, los workers, las conexiones a bases de datos, las cachés, el almacenamiento de objetos y el tráfico de salida (egress) pueden ser compartidos; aislar únicamente el ingreso permite que el ruido penetre aguas abajo.

Segundo, ¿puede distinguir entre cuotas, programación equitativa y aislamiento estricto? Los token buckets por inquilino limitan el volumen, las colas justas eligen quién se ejecuta a continuación y los shards o grupos dedicados delimitan los fallos. Resuelven problemas distintos.

Tercero, ¿puede razonar sobre el balance de costos entre inquilinos grandes y pequeños? La dedicación completa genera capacidad ociosa y sobrecarga operativa; compartir todo crea contención. Una respuesta sólida ofrece niveles (tiers) y activadores de migración.

Cuarto, ¿puede demostrar el aislamiento? Mida la latencia, los rechazos, la antigüedad de las colas, el consumo de cuotas, los reintentos y los descartes por inquilino, cola y capa de recursos, en lugar de depender de promedios globales.

Preguntas de clarificación

• ¿Cuáles son los objetivos del servicio? Defina p95, tiempo de espera máximo, tasa de éxito y disponibilidad regional para el trabajo interactivo y asíncrono.
• ¿Qué trabajos tienen prioridad? Los niveles de contrato, el trabajo humano urgente, los reportes programados y la exploración pueden tener diferentes ponderaciones.
• ¿Cuáles son los límites de datos y recursos? ¿Algunos inquilinos necesitan una base de datos, región, clave, almacén de objetos o grupo de workers independiente?
• ¿Cómo se miden las ráfagas y las cuotas a largo plazo? ¿Tasa de envío, trabajos concurrentes, bytes escaneados, tiempo de CPU, almacenamiento o egress?
• ¿Cómo perciben los usuarios las colas y los rechazos? La finalización estimada, la guía de reintentos, la explicación de cuotas y los reportes para administradores deben ser explícitos.

Respuesta de 30 segundos

“Primero defino los objetivos de latencia, éxito, concurrencia y aislamiento de datos por inquilino y plan, separando las cuotas de envío, la concurrencia en ejecución y los presupuestos aguas abajo. El gateway autentica al inquilino, valida el tamaño del trabajo y una clave de idempotencia, y escribe en una cola duradera. Un programador utiliza token buckets por inquilino y colas equitativas ponderadas; los inquilinos ruidosos o regulados pueden trasladarse a grupos de workers dedicados o con shuffle sharding. Los escaneos de base de datos, cachés, almacenamiento de objetos y egress también se miden. Durante una sobrecarga, se rechaza o difiere el trabajo de baja prioridad con estados verídicos y soporte de cancelación. Se valida con pruebas de autorización cruzada entre inquilinos, inyección de ruido, simulacros de fallos y aserciones de p99 por inquilino, radio de impacto y recuperación”.

Respuesta paso a paso

Paso 1: Definir recursos y objetivos de servicio

Divida un reporte en envío, encolado, consulta, generación, escritura de objetos y descarga. Defina un objetivo medible para cada uno, como el p95 de envío, la antigüedad de la cola, el tiempo de finalización, el éxito de la descarga y el aislamiento. Asigne presupuestos para CPU, memoria, escaneos, conexiones, ranuras de cola, solicitudes de objetos y egress en lugar de limitarse a nombrar una cantidad de workers.

Paso 2: Establecer un contexto de inquilino confiable

La identidad del inquilino proviene de credenciales autenticadas y autorización del servidor, no de un tenantId suministrado por el cliente. Los trabajos, mensajes de cola, consultas, rutas de objetos, claves de caché y tokens de descarga deben llevar un contexto verificado. Limite los campos, las ventanas de tiempo y los escaneos máximos para que un inquilino legítimo no pueda agotar los recursos compartidos con una consulta demasiado amplia.

authenticated principal
  -> authorize tenant and report definition
  -> assign quota class and priority
  -> enqueue {tenantId, taskId, costEstimate, deadline}
  -> every worker and storage call re-checks tenant scope

Paso 3: Elegir niveles de aislamiento

Los inquilinos pequeños pueden compartir colas y workers con cuotas por inquilino, límites de concurrencia y programación equitativa. Los inquilinos de alto volumen o regulados pueden recibir una cola dedicada, una partición, un esquema de base de datos, una clave de cifrado o un grupo de workers dedicado. El shuffle sharding de AWS mapea cada inquilino a una combinación de workers para que la falla de un worker afecte a menos inquilinos; esto delimita el radio de impacto mientras conserva cierta eficiencia de uso compartido.

Paso 4: Diseñar cuotas y programación equitativa

Utilice un token bucket de envío para ráfagas de ingreso, un límite de concurrencia para trabajos en curso y un presupuesto de costos para bytes escaneados o CPU. Una cola equitativa ponderada o una cola virtual por inquilino evita que un solo inquilino ocupe todos los workers; dentro de un inquilino, ordene por prioridad, fecha límite y antigüedad. El rechazo debe ser un estado explicable de sobrecarga temporal o de cuota, no una invitación a reintentar indefinidamente.

Paso 5: Proteger los recursos aguas abajo

Inicie un trabajo solo después de que el programador disponga de presupuesto para base de datos, caché y almacenamiento de objetos. Utilice réplicas de lectura, ventanas de tiempo y límites de escaneo para los reportes; particione los resultados por inquilino y región y emita autorizaciones de descarga de corta duración. Si las conexiones, cachés, hilos y el egress siguen compartiéndose globalmente, la equidad en el ingreso no evitará la inanición aguas abajo. Asigne a las dependencias críticas sus propios límites de concurrencia y colas acotadas.

Paso 6: Manejar ráfagas, fallos y recuperación

Persista el estado del trabajo, la instantánea de la cuota, una clave de idempotencia y la cancelación. Un worker que falla puede reintentar, pero las escrituras de resultados deben ser idempotentes mediante una versión o clave de resultado. Cuando una dependencia no esté disponible, pause solo las clases afectadas, preserve la antigüedad de la cola y las estimaciones, y evite una tormenta de reintentos masiva. Al recuperarse, aumente gradualmente la admisión por inquilino y prioridad mientras monitorea el p99, los errores y la cuota, en lugar de liberar todo el trabajo acumulado de golpe.

Paso 7: Escalar, migrar y validar

Escale en función del rendimiento útil, la antigüedad de la cola, la utilización de recursos y las ponderaciones de los inquilinos, no únicamente por el promedio de CPU. Al mover un inquilino de un grupo compartido a un shard dedicado, preserve el estado idempotente del trabajo y las rutas de resultados, realice el cambio gradualmente y mantenga la capacidad de rollback. Pruebe la autorización entre inquilinos, la inyección de ruido, el fallo de un worker, una base de datos lenta, la recuperación de colas, las cancelaciones y la migración de inquilinos grandes; cada prueba verifica que los demás inquilinos sigan cumpliendo sus objetivos.

Respuesta de muestra de alta calidad

“Dividiría el reporte en envío, encolado, consulta, generación, almacenamiento y descarga, y definiría objetivos de latencia, éxito y aislamiento para cada etapa. La identidad del inquilino proviene de un contexto autenticado y el servidor vuelve a autorizar la definición del reporte; un campo de inquilino en la solicitud es una entrada, no un límite de seguridad. Los trabajos ingresan a una cola duradera con el inquilino, la estimación de costos, la clave de idempotencia y el plazo límite.

Los inquilinos pequeños comparten workers, pero cada uno tiene cuotas de tasa de envío, tareas en curso, bytes escaneados y almacenamiento. La programación equitativa ponderada con prioridad por antigüedad evita que una ráfaga de fin de mes acapare todos los workers. Los inquilinos regulados o de alto volumen pueden trasladarse a una cola dedicada, partición o grupo de workers con shuffle sharding para reducir el radio de impacto ante la falla de un worker o un inquilino sobrecargado. Las conexiones a bases de datos, cachés, almacenamiento de objetos y egress también reciben presupuestos por inquilino o por clase.

En caso de sobreuso, devuelvo un estado honesto de cola o sobrecarga temporal y permito la cancelación; los clientes no pueden reintentar indefinidamente. Los workers utilizan claves de resultado idempotentes, mientras que una falla de dependencias solo pausa el trabajo afectado y la recuperación se realiza de forma progresiva por inquilino y prioridad.

Validaría esto con pruebas de acceso entre inquilinos, ráfagas de un solo inquilino, fallos en workers y bases de datos, reproducción de colas, cancelaciones y ejercicios de migración. Inspeccionaría el p99, la antigüedad de la cola, la tasa de rechazo, el uso de recursos y las aserciones de fugas de cada inquilino. Solo ampliaría un grupo de aislamiento o ajustaría las ponderaciones después de confirmar que tanto los inquilinos pequeños como los de nivel superior cumplen con sus objetivos”.

Errores comunes

• Confiar en tenantId desde la solicitud → Un cliente puede falsificar el alcance → Derívelo de la autenticación y verifíquelo nuevamente aguas abajo.
• Asignar a cada inquilino un worker fijo → La capacidad ociosa aumenta y los fallos aún se propagan → Utilice niveles de riesgo y shards combinados según sea necesario.
• Limitar únicamente la tasa de envío → El trabajo en curso aún satura los recursos aguas abajo → Limite también la concurrencia, el costo y las dependencias.
• Usar promedios globales para la equidad → La latencia de cola de los inquilinos pequeños se oculta → Registre p95, p99, colas y rechazos desglosados por inquilino.
• Reintentar indefinidamente bajo sobrecarga → La amplificación de reintentos tumba el servicio → Devuelva un estado explícito, reintentos idempotentes y presupuestos compartidos.
• Agregar workers sin un presupuesto para la base de datos → La dependencia se convierte en el cuello de botella → Presupueste cada capa de recursos de extremo a extremo.
• Liberar todo el trabajo acumulado durante la recuperación → Se genera un nuevo pico de carga → Utilice histéresis y admisión gradual.
• Migrar sin un estado idempotente → Se duplican trabajos o se pierden resultados → Utilice versiones, claves de resultados y rollback.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿En qué se diferencia el shuffle sharding del sharding ordinario?

El sharding ordinario generalmente ubica a un inquilino en un único shard fijo, por lo que la falla de un shard afecta a todos los inquilinos alojados allí. El shuffle sharding asigna a cada inquilino una combinación de workers con solapamiento limitado, reduciendo el conjunto afectado por la caída de un worker. Introduce consideraciones sobre capacidad, rebalanceo y migración de inquilinos con alta carga.

Pregunta de seguimiento 2: ¿Puede un inquilino premium eludir la programación equitativa?

Asígnele una ponderación contractual o de pago explícita, pero mantenga la capacidad total, el aislamiento y los límites de seguridad. Reserve presupuesto para el trabajo premium mientras registra un objetivo de servicio mínimo para los inquilinos ordinarios; “prioridad” no debe significar una apropiación ilimitada de recursos (preemption).

Pregunta de seguimiento 3: ¿Qué sucede si un reporte escanea toda la base de datos?

Estime el costo durante el análisis y la planificación de la consulta, exija un rango de fechas, limite los bytes y la concurrencia, y divida, difiera o rechace el trabajo que supere el presupuesto. Un pool de base de datos más grande solo traslada la presión al almacenamiento y no representa una solución completa.

Pregunta de seguimiento 4: ¿Cómo demuestra que no hay filtraciones entre inquilinos?

Construya una matriz de acceso basada en entidades autenticadas a través de API, reproducción de colas, workers, cachés, rutas de objetos, exportaciones y herramientas de administración. Agregue pruebas negativas para que los contextos faltantes o falsificados sean denegados por defecto, y valide las etiquetas de inquilino y el contenido en resultados reales.