Defina el cliente como límite comercial y técnico
SaaS describe la forma de prestar un producto; la arquitectura multiinquilino es una manera de compartir sus componentes. Microsoft diferencia expresamente ambos conceptos en su guía. Un inquilino puede ser una empresa, un equipo u otro grupo cuyos usuarios comparten información y configuración. Antes de elegir tablas, aclare quién crea la organización, quién la administra, cómo entra un usuario y si puede trabajar en varias. Sin esa definición, corregir permisos más tarde resulta difícil.
Trace el ciclo de vida: alta, invitación, cambio de plan, suspensión, exportación y cierre. En cada paso indique quién posee los datos, cuándo surte efecto el cambio y qué ocurre con el acceso. Cerrar una organización no implica siempre borrar inmediatamente todos sus registros; la conservación depende del contrato y del contexto legal concreto. El modelo técnico debe permitir ejecutar y explicar esas decisiones. La primera versión puede ser pequeña, pero la frontera entre clientes debe ser explícita.
Compruebe el aislamiento en todas las rutas a datos
Compartir aplicación y base de datos puede ser un comienzo razonable si el contexto de cada cliente se impone de modo uniforme. Bases o entornos separados aumentan la frontera de aislamiento, pero añaden despliegues, migraciones y vigilancia. Microsoft describe los compromisos entre coste, rendimiento y separación de varios enfoques. No existe un modelo único para todos. La elección depende de sensibilidad, contratos, tamaño de cada organización y capacidad real del equipo operativo.
Pruebe más que una consulta de pantalla. El contexto puede perderse dentro de un trabajo asíncrono, exportación, caché, índice de búsqueda o herramienta administrativa. Cada ruta debe llevar identidad, organización y permisos hasta los datos. Ensaye casos negativos: un usuario cambia el identificador en la URL, un proceso lee un lote equivocado o la caché devuelve una respuesta ajena. Los registros deben explicar incidentes sin copiar innecesariamente información sensible.
Los permisos del producto y la facturación son dominios distintos
El catálogo de funciones, los permisos internos y la suscripción financiera pueden cambiar en momentos diferentes. Un proveedor externo puede encargarse de facturas y pagos; su aplicación sigue decidiendo qué capacidades puede usar cada organización ahora mismo. Modele el derecho interno, su origen, fecha efectiva y política para eventos tardíos. No conceda acceso permanente solo porque apareció una página de pago exitoso en el navegador. Esa pantalla no demuestra todo el ciclo financiero.
Stripe documenta eventos separados para cambios de suscripción, facturas y fallos de pago. Si se elige un proveedor parecido, la integración debe verificar eventos, tratar con seguridad entregas repetidas y conciliar resultados ambiguos. La aplicación no necesita asumir la función de procesador de pagos sin motivo explícito. Las reglas para periodos de prueba, cambio de tarifa y final del acceso deben acordarse con el responsable del producto; no se deducen automáticamente de una referencia API.
Mida el crecimiento de datos por organización
El número total de usuarios oculta diferencias. Un cliente grande puede producir la mayoría de registros, informes costosos o picos extremos. Mida tamaño, peticiones, latencia y coste por organización donde la privacidad lo permita. Ponga límites a operaciones exigentes y explique qué verá el usuario al alcanzarlos. Escalar una base no sustituye la corrección de una consulta que carga todo el histórico para cada cliente. La observación debe llevar a una mejora concreta.
Mida primero el cuello de botella real. Un índice, procesamiento por lotes o flujo de informes independiente puede ser mejor que dividir el producto entero en servicios. En la caché identifique qué valores son compartidos y cuáles pertenecen a una sola organización. Siga también creación y eliminación de datos; sin ciclo de vida el volumen crece indefinidamente. Las pruebas de rendimiento deben incluir clientes pequeños y grandes trabajando a la vez, no solo solicitudes sintéticas repartidas uniformemente.
Publique cambios sin caída compartida
Una versión común para todos simplifica el mantenimiento, pero un cambio puede afectar a todo el producto. Hace falta activar gradualmente, vigilar el impacto y poder volver. Añada primero un campo compatible en la base, migre datos y solo después retire el uso antiguo. Así puede desplegar mientras siguen activos trabajos o clientes anteriores. Use indicadores de funciones con moderación y asigne a cada uno fecha de retirada. Una colección permanente de indicadores acaba siendo otro sistema difícil de entender.
Volver a un contenedor anterior no basta cuando la versión cambió datos. Prepare un procedimiento para migración incompleta, exportación fallida y clientes con versiones diferentes. Antes del lanzamiento compruebe acceso entre organizaciones, permisos de roles, eventos de facturación y contratos de integración importantes. La herramienta importa menos que saber qué versión funciona, quién se ve afectado y cómo detectar regresiones. Un cambio de flujo también puede requerir avisar a los clientes.
Observe la experiencia real del cliente
Un proceso activo no equivale a producto útil. Para cada recorrido crítico mida fallos, tiempo hasta completar y operaciones pendientes de intervención humana. Separe el problema de una organización de una caída de infraestructura compartida. El personal de soporte necesita consultar una operación concreta sin acceso general a los datos de todos. Cada lectura de un registro sensible debe responder a una razón y a un permiso adecuado.
Durante un incidente asigne quién puede desactivar la función nueva, quién comunica y quién revisa después los datos. Una copia de la base por sí sola no es un plan de recuperación. Compruebe que se puede restaurar la aplicación con un esquema compatible, almacenamiento de objetos y configuración, y piense en el efecto de recuperar un cliente sobre los demás. Defina límites realistas de pérdida de datos y tiempo de retorno según el impacto comercial, no según publicidad de infraestructura.
Cuándo cambiar la arquitectura y cómo empezar
Un rediseño mayor se justifica con pruebas repetibles: imposibilidad de aislar a un cliente sensible, migraciones demasiado lentas, coste desproporcionado de una carga o riesgo de lanzamiento que cambios menores no resuelven. Registre medidas e incidentes que sostienen la decisión. Después encuentre la frontera mínima útil: quizá un proceso de informes separado o almacenamiento distinto para clientes muy grandes. Una reescritura completa sin límites comprobados puede simplemente mover el problema.
El piloto debe cubrir alta de una organización, cambio de plan, fallo de un evento de facturación, carga de un cliente grande, exportación y eliminación de datos. Esta página no afirma que EXCOIN opere un número concreto de clientes SaaS ni tenga acuerdos con un proveedor financiero. Primeros resultados útiles son mapa de organizaciones y datos, modelo de acceso, lista de recorridos críticos y medidas que muestren dónde se necesita de verdad un cambio. Esas observaciones justifican el siguiente paso.