En las salas de arquitectura de medio mundo, una confusión silenciosa está moldeando decisiones técnicas que luego pagan caro los equipos de ingeniería. Alguien dice "vamos a hacer multi-tenant" y, casi por reflejo pavloviano, el siguiente comentario asume que eso implica diseñar un sistema distribuido. El soldadura entre ambos conceptos es fuerte, extendida y, fundamentalmente, errónea.
El multi-tenancy es un modelo de tenencia: una única instancia de software sirve a múltiples clientes (tenants) aislando sus datos y configuración. Un sistema distribuido, en cambio, es una topología de despliegue: componentes que se ejecutan en nodos de red separados y se comunican por mensaje. Uno resuelve "cómo compartimos recursos entre clientes"; el otro, "cómo escalamos y toleramos fallos a través de la red". Mezclarlos sin criterio lleva a sobreingeniería prematura o, peor, a aislamiento roto.
La confusión tiene raíces comprensibles. Las plataformas SaaS modernas —y ahora los servicios de inferencia de LLMs— suelen nacer multi-tenant y, al crecer, terminan distribuidas. Pero el orden causal no implica identidad. Puedes tener multi-tenancy en un monolito bien modularizado (ejemplo: GitHub Enterprise en sus inicios) y puedes tener sistemas distribuidos single-tenant (ejemplo: clústeres dedicados por cliente en entornos regulados).
En el contexto actual de IA, el error cobra nueva dimensión. Los proveedores de modelos como servicio (MLaaS) enfrentan presión para ofrecer aislamiento estricto de datos de entrenamiento, latencia predecible y facturación por uso. Muchos equipos responden desplegando microservicios por tenant: un error que multiplica la superficie de ataque, la complejidad operativa y el coste de GPU ociosa. La alternativa madura es multi-tenancy a nivel de plano de control con particionado de recursos (Kubernetes namespaces, GPU MIG, colas de inferencia con prioridad) manteniendo el plano de datos lo más simple y centralizado posible.
¿Por qué persiste el mito? Tres factores: marketing de proveedores de infraestructura que venden "distribuido" como sinónimo de "moderno"; currículos que enseñan patrones distribuidos antes que modelos de tenencia; y la tendencia humana a buscar balas de plata arquitectónicas. La solución no es evitar lo distribuido, sino decidirlo por las razones correctas: latencia geográfica, tolerancia a fallos de zona, escalado elástico independiente. No porque "tenemos muchos tenants".
Para los CTOs y staff engineers que lean esto: auditen su arquitectura actual. Pregunten cuántos servicios existen solo para aislar tenants y si ese aislamiento no se lograría con row-level security, esquemas por tenant en PostgreSQL o particiones lógicas en la cola de inferencia. Cada servicio distribuido eliminado es un incidente menos a las 3 AM, una factura de cloud menor y un deploy más rápido. La arquitectura no es colección de patrones de moda; es el arte de decir no a la complejidad innecesaria.
