Какую проблему мы решаем
Когда одним продуктом пользуются разные компании или группы клиентов, архитектуре приходится отвечать на неприятный вопрос: насколько сильно они должны быть отделены друг от друга?
Если все используют общие вычисления и общую базу, продукт обычно дешевле масштабировать и проще обновлять. Но ошибка в фильтрации данных, перегрузка одного крупного клиента или неудачный релиз потенциально затрагивают больше людей.
Если для каждого клиента создавать отдельную инфраструктуру, границы становятся жёстче. Одновременно растёт количество сред, конфигураций, обновлений и вещей, которые нужно обслуживать.
Как работает подход
Multi-tenancy — это не одна конкретная схема. Изоляцию можно строить на разных уровнях: общая база с идентификатором клиента, отдельные схемы или базы, отдельные вычислительные ресурсы, отдельные кластеры или даже полностью выделенные среды.
Поэтому полезнее говорить не «у нас multi-tenant», а отдельно определить границы для данных, вычислений, сетевого доступа, ключей, конфигурации и релизов.
Часто разумная архитектура получается гибридной: большинство клиентов используют общую платформу, а для некоторых требований появляется более сильная изоляция.
Что получает бизнес
Главное преимущество общей платформы — экономия масштаба. Один релиз, одна инфраструктурная модель и общие ресурсы позволяют обслуживать больше клиентов без линейного роста стоимости.
Более сильная изоляция, наоборот, может быть нужна для крупных клиентов, требований безопасности, регулирования или особых нагрузок. Она уменьшает вероятность того, что проблема одного клиента станет общей проблемой.
Поэтому multi-tenancy напрямую влияет на unit economics продукта, стоимость enterprise-сегмента и допустимый бизнес-риск.
Что получает команда
Команда получает явную модель tenant-контекста: как определяется клиент, где проверяется доступ, как ограничиваются ресурсы, как устроены миграции и как расследовать инцидент для конкретного tenant.
Хорошая модель уменьшает количество специальных исключений. Плохая быстро превращается в набор условий «для этого клиента иначе», которые усложняют каждый релиз.
Что получает клиент
Клиенту важны не архитектурные термины, а последствия: его данные не должны попадать к соседу, чужая нагрузка не должна делать продукт непригодным, а изменение для другого клиента не должно неожиданно ломать его работу.
Для части клиентов дополнительная изоляция также упрощает выполнение внутренних требований к безопасности и аудиту.
Чем мы за это платим
Чем сильнее изоляция, тем выше стоимость инфраструктуры и операций. Нужно обновлять больше сред, следить за большим количеством конфигураций, проводить миграции и сохранять наблюдаемость между изолированными частями.
Слабая изоляция дешевле, но требует безошибочной дисциплины в правах доступа, запросах к данным и контроле ресурсов. Ошибка может иметь больший радиус.
Когда не нужно усложнять
Не каждому продукту нужна отдельная база или среда на клиента. Если требования одинаковы, риски приемлемы, а масштаб ещё невелик, преждевременная изоляция создаст больше эксплуатационной работы, чем ценности.
И наоборот, опасно пытаться решить enterprise-требования несколькими условиями в коде, если цена смешивания данных или общего сбоя уже стала высокой.
Что стоит спросить перед решением
- Какой максимальный ущерб допустим, если один tenant перегрузит систему?
- Насколько критично физически или логически разделять данные?
- Есть ли клиенты с отдельными требованиями к безопасности или размещению?
- Нужно ли выпускать изменения для клиентов в разном темпе?
- Сколько дополнительной инфраструктуры и операций мы готовы поддерживать?
В итоге
Multi-tenancy — это выбор границы между экономией масштаба и изоляцией риска. Универсально правильной глубины разделения нет.
Для бизнеса хороший multi-tenancy означает не максимальную изоляцию, а минимально достаточную изоляцию, которая удерживает риск на приемлемом уровне и не разрушает экономику продукта.