Multitenancy, o multitenencia, es un principio arquitectónico en el que una única instancia de una aplicación de software y su infraestructura asociada sirven a múltiples organizaciones o usuarios, conocidos como 'tenants'. Cada tenant tiene una vista lógica de su propia aplicación y datos, con aislamiento garantizado de los demás tenants. Este aislamiento se puede lograr a nivel de datos (esquemas separados, prefijos de tabla, o columnas de tenant_id), a nivel de aplicación (sandboxing lógico), o a nivel de infraestructura (contenedores o VMs dedicadas por tenant, aunque esto último es menos común en la definición estricta de multitenancy). El objetivo principal es maximizar la eficiencia de los recursos y reducir los costos operativos al compartir la base de código, la infraestructura y, a menudo, la base de datos.
La multitenencia es la base de muchos servicios SaaS (Software as a Service) modernos. Ejemplos concretos incluyen plataformas CRM como Salesforce, donde miles de empresas comparten la misma instancia de la aplicación, pero sus datos y configuraciones están estrictamente separados. Plataformas de computación en la nube como AWS, Azure y Google Cloud Platform también emplean principios de multitenencia a nivel de infraestructura, donde múltiples clientes comparten el hardware físico subyacente, pero sus recursos (VMs, redes, almacenamiento) están virtualmente aislados. Bases de datos como Amazon RDS o Google Cloud SQL, que ofrecen instancias de bases de datos gestionadas, a menudo utilizan multitenencia para optimizar el uso de los recursos subyacentes del servidor de base de datos.
Para un arquitecto, la multitenencia es una decisión estratégica con importantes trade-offs. Ofrece una reducción significativa en los costos de infraestructura y operación, una gestión de software simplificada (una única versión para mantener y actualizar) y una mayor agilidad en el despliegue de nuevas características. Sin embargo, introduce desafíos complejos en el aislamiento de datos y seguridad, el rendimiento (el 'noisy neighbor' problem), la personalización para tenants específicos y la gestión de la capacidad. La elección entre un modelo 'shared-everything' (el más eficiente pero con mayores riesgos de aislamiento) y modelos con mayor segregación (como 'shared-database, separate-schema' o 'separate-database') depende de los requisitos de seguridad, cumplimiento, rendimiento y escalabilidad de los tenants, así como de la complejidad de la gestión de datos y la estrategia de respaldo y recuperación. Un diseño robusto requiere una cuidadosa consideración de la arquitectura de datos, la seguridad a nivel de aplicación y la monitorización granular del rendimiento por tenant.