Aislamiento de tenantes y límites

El aislamiento de tenantes y límites es la base de la arquitectura multi-tenant. Objetivo: que las acciones de un inquilino nunca afecten a los datos, la seguridad y el SLO de otro, y que los recursos se distribuyan de forma equitativa y previsible. A continuación, un mapa práctico de soluciones desde el nivel de datos hasta la planificación computacional y la gestión de incidentes.

1) Modelo de amenazas y objetivos

Amenazas

Filtración de datos entre inquilinos (lógico/por caché/a través de registros).
«Noisy neighbor»: degradación del rendimiento debido a picos en un solo cliente.
Escalamiento de privilegios (error en la directiva de acceso).
Facturación a la deriva (no coincidencia de uso y devengo).
Escenarios de tolerancia a fallas en cascada (el incidente de uno lleva al downtime de muchos).

los Objetivos

Estricto aislamiento de datos y secretos.
Límites/cuotas per-tenantes y planificación equitativa.
Auditoría transparente, observabilidad y facturación.
Localización de incidentes y recuperación rápida por tenant.

2) Niveles de aislamiento (modelo de extremo a extremo)

1. Datos

'tenant _ id' en claves e índices, Row-Level Security (RLS).
Cifrado: jerarquía KMS → clave de arrendatario (KEK) → clave de datos (DEK).
Esquemas separados/DAB bajo requisitos altos (Silo), clúster común c RLS para eficiencia (Pool).
Políticas de retiro y «derecho al olvido» por tenant, crypto-shredding claves.

2. Cálculos

Cuotas de CPU/RAM/IO, grupos de workers por tenant, colas «ponderadas».
Aislamiento GC/heap (contenedores/ajustes JVM/Runtime), límites en parallelismo.
Pen-tenant autoscaling + backpressure.

3. Red

Segmentación: private endpoints/VPC, ACL por 'tenant _ id'.
Rate limiting y per-tenant connection caps en el límite.
Protección contra DDoS/bots teniendo en cuenta el plan/prioridad.

4. Operaciones y procesos

Migraciones de alquiler, backups, DR, feature-flags.
Los incidentes son un «radio micro-blast»: el fusión por 'tenant _ id'.

3) Control de acceso y contexto del inquilino

AuthN: OIDC/SAML; los tokens llevan 'tenant _ id', 'org _ id', 'plan', 'scopes'.
AuthZ: RBAC/ABAC (roles + atributos del proyecto, departamento, región).
Contexto en la frontera: La puerta de enlace API recupera y valida el contexto del tenant, complementa con límites/cuotas, escribe en tracks.
Principio de «doble bloqueo»: verificación en el servicio + RLS/política de DB.

4) Datos: esquemas, caché, registros

• Shared-schema (row-level): máxima eficiencia, el RLS estricto es obligatorio.
• Per-schema: compromiso de aislamiento/operabilidad.
• Per-DB/cluster (Silo): para VIP/ajustable.

Caché: prefijos de clave 'tenant: {id}:...', TTL por planes, protección contra cache-stampede (lock/early refresh).

Registros/metadatos: seudonimización completa de PII, filtros por 'tenant _ id', prohibición de «pegar» los registros de diferentes inquilinos.

5) Limitar el tráfico y las operaciones

Mecánica básica

Token Bucket: ráfagas suavizadas, parametrización 'rate '/' burst'.
Leaky Bucket: estabilización de throughput.
Ventana fija/ventana deslizante: cuotas simples/precisas por ventana de tiempo.
Concurrency limits: caps para consultas/jobs simultáneos.

En la frontera (puerta de enlace L7/API) es la principal protección y «falla rápida».
En el núcleo (en servicios/colas) - para el segundo circuito y «fair share».

Por tenante/plan/endpoint/tipo de operación (API públicas, exportaciones pesadas, acciones administrativas).
Priority-aware: VIP obtiene mayor 'burst' y peso al arbitrar.
Idempotency-keys para retiros seguros.

Ejemplos de perfiles (conceptos)

Inicio: 50 req/s, burst 100, 2 exportaciones paralelas.
Business: 200 req/s, burst 400, 5 exportaciones.
Enterprise/VIP: 1000 req/s, burst 2000, workers dedicados.

6) Cuotas y planificación equitativa (fairness)

Cuotas de recursos: almacenamiento, objetos, mensajes/min, trabajos/hora, tamaño de cola.
Weighted Fair Queuing/Deficit Round Robin: acceso «ponderado» a los talleres compartidos.
pools de trabajo Per-tenant: aislamiento duro para clientes ruidosos/críticos.
Control de Admision: falla/degradación antes de la ejecución cuando se agotan las cuotas.
Backoff + jitter: retardos exponenciales para no sincronizar las ráfagas.

7) Observabilidad y facturación por tenant

Etiquetas obligatorias: 'tenant _ id', 'plan', 'región', 'endpoint', 'status'.
SLI/SLO per tenant: p95/p99 latency, error rate, availability, utilization, saturation.
Métricas de uso: contadores por operación/bytes/segundos de CPU → agregador → facturas.
Idempotencia de facturación: snapshots en la frontera, protección contra double download/pérdida de eventos.
Dashboards por segmentos: VIP/regulables/nuevos inquilinos.

8) Incidentes, degradación y DR «por inquilinos»

Fusing por 'tenant _ id': desconexión de emergencia/atornillamiento de un inquilino particular sin afectar al resto.
Degradación Graceful: modo sólo lectura, colas en «sandbox», tareas retrasadas.
RTO/RPO per tenant: valores objetivo de recuperación y pérdida para cada plan.
Ejercicios: «días de juego» regulares con el inquilino ruidoso apagado y verificación de DR.

9) Cumplimiento (residencia, privacidad)

Pinning tenant a la región; reglas claras para los flujos cruzados-regionales.
Auditoría de acceso a claves/datos, registro de operaciones de administración.
Control de retoque y exportación de datos per tenant.

10) Mini-referencia: cómo juntar

Flujo de consulta

1. Edge (API-gateway): TLS → extraer 'tenant _ id' → validar el token → aplicar rate/quotas → colocar los tracks.
2. Motor Polisi: contexto 'tenant _ id/plan/features' → decisión de ruta y límites.
3. Servicio: validación de derechos + etiquetas 'tenant _ id' → trabajar con una DB bajo RLS → caché prefijada.
4. Colección de uso: contadores de operaciones/bytes → agregador → facturación.

Datos

Diagrama/DB por estrategia (row-level/per-schema/per-DB).
KMS: llaves en el inquilino, rotación, crypto-shredding cuando se elimina.

Colas con escalas, grupos de workers per tenant, caps por concurrency.
Autoscaling por métricas de pluma.

11) Pseudo-política (para orientación)

yaml limits:
starter:
req_per_sec: 50 burst: 100 concurrency: 20 exports_parallel: 2 business:
req_per_sec: 200 burst: 400 concurrency: 100 exports_parallel: 5 enterprise:
req_per_sec: 1000 burst: 2000 concurrency: 500 exports_parallel: 20

quotas:
objects_max: { starter: 1_000_000, business: 20_000_000, enterprise: 100_000_000 }
storage_gb: { starter: 100,   business: 1000,    enterprise: 10000 }

12) Lista de verificación antes de la venta

• Una única fuente de verdad 'tenant _ id'; por todas partes se mueve y se lógica.
• RLS/ACL activado a nivel de BD + verificación de servicio (doble bloqueo).
• Claves de cifrado por tenant, rotación/eliminación documentada (crypto-shredding).
• Límites/cuotas en la frontera y en el interior; picos y «burst» probados.
• Fair-queuing y/o workers dedicados para VIP; caps на concurrency.
• SLO y alertas per-tenantes; dashboards por segmentos.
• La colección usage es idempotente; Se ha comprobado la relación con la facturación.
• Los DR/incidentes se localizan al inquilino; El fusing por 'tenant _ id' lo practica.
• Caché/registros divididos por inquilinos; PII camuflado.
• Los procedimientos de migración/backup/exportación son de alquiler.

13) Errores típicos

RLS deshabilitado/evitado por el usuario «de servicio» - riesgo de fuga.
Un solo límite global → «noisy neighbor» y una violación de SLO.
Cachés/colas compartidas sin prefijos → intersección de datos.
Facturación cuenta por logos que se pierden en picos.
La ausencia de un fusing de alquiler son caídas en cascada.
Migraciones «de un solo golpe» sin la posibilidad de pisotear el problemático 'tenant _ id'.

14) Selección rápida de la estrategia

Regulable/VIP: Silo-data (per-DB), workers dedicados, cuotas estrictas y residency.
SaaS masivo: Shared-schema + RLS, límites fuertes en la frontera, fair-queuing en el interior.
Carga «ruidosa/pulsante»: grandes 'burst' + duros concurrency-caps, retroceso y prioridades por planes.

El aislamiento de tenantes y los límites son sobre fronteras y justicia. Un claro 'tenant _ id' a través de la pila, el RLS y el cifrado de datos, el límite y las cuotas en la frontera y en el núcleo, un planificador justo, la vigilancia y la localización de incidentes - todo esto juntos da seguridad, calidad predecible y facturación transparente para cada inquilino, incluso con el crecimiento agresivo de la plataforma.