Представим SaaS-продукт, которым пользуются две компании. Один клиент запускает тяжёлую выгрузку, а второй внезапно начинает ждать ответа значительно дольше. Или хуже: ошибка в фильтрации показывает человеку чужие данные. В обоих случаях компания решила разделить клиентов недостаточно строго — хотя причины и последствия у этих случаев разные.
Multi-Tenancy — это не конкретная технология, а выбор того, какие ресурсы клиенты разделяют и где проходит граница изоляции.
Что выгодно разделять, а что опасно
Общее приложение и инфраструктура позволяют не содержать отдельный сервер для каждого клиента, централизованно выпускать обновления и лучше использовать мощности. Именно на этом часто строится экономика SaaS.
Но общие ресурсы создают соседские зависимости. Один клиент может забрать вычисления, очередь или подключения к базе. Ошибка в проверке tenant ID способна превратить программный дефект в утечку данных между компаниями.
Поэтому изоляцию стоит рассматривать по отдельным измерениям: доступ к данным, вычисления, сетевые и операционные границы, скорость обновлений, восстановление после аварии. Отдельная база не исправляет ошибки авторизации, а общий процесс не обязательно означает полное отсутствие изоляции.
Один SaaS — несколько разумных уровней разделения
Варианты начинаются с общих таблиц с обязательной привязкой к клиенту. Дальше можно выделять отдельные схемы или базы. Для части клиентов могут понадобиться самостоятельные окружения или собственные требования к размещению данных.
Чем глубже разделение, тем обычно выше операционная цена: миграции, резервное копирование, мониторинг, обновления и поддержка начинают множиться. Не стоит выбирать максимальную изоляцию автоматически. Важно соотнести её с последствиями ошибки и требованиями договора.
Крупный клиент меняет нагрузку для остальных
Изоляция безопасности и изоляция ресурсов — разные задачи. Даже если данные надёжно разграничены, один большой клиент может забить общую очередь или исчерпать пул подключений. Для таких ситуаций нужны лимиты, квоты, отдельные пулы или разделение наиболее тяжёлых нагрузок.
При этом лимиты должны соответствовать продуктовым обещаниям. Нельзя неожиданно запрещать легитимную активность клиента, если тариф и договор подразумевают иной режим.
Как проверить архитектурный выбор
Я бы предложил пройти четыре сценария: ошибочный запрос за чужими данными, пик нагрузки крупного клиента, восстановление одного клиента из резервной копии и обновление, которое нужно выпустить не всем одновременно.
Эти сценарии быстро показывают, где разделение действительно необходимо. Иногда достаточно усилить авторизацию и квоты. Иногда оправдана отдельная база. А иногда изолированное окружение — требование самого бизнеса.
Хорошая multi-tenant архитектура не стремится разделить всё. Она удерживает риск соседства в приемлемых границах, не разрушая экономику общей платформы.