Архитектура SaaS-платформы: три подхода к мульти-арендности

Архитектура SaaS-платформы отличается от обычного веб-приложения одним фундаментальным решением — мульти-арендностью. Если ваше приложение должно одновременно обслуживать сотни клиентов с изолированными данными по одной кодовой базе, вам нужен паттерн multi-tenant. От того, какой из трёх классических подходов вы выберете, зависят расходы на инфраструктуру, скорость обновлений, безопасность данных и потолок масштабирования.

Эта статья — практический разбор для основателя и архитектора, который проектирует архитектуру SaaS-платформы и выбирает между «общей схемой», «схемой-на-арендатора» и «базой-на-арендатора». Без академизма, с критериями выбора, типовыми ошибками и сценариями миграции.

Что такое архитектура SaaS-платформы

SaaS-платформа — это программный продукт, доставляемый клиентам через интернет по модели подписки. Архитектурно это означает четыре требования:

• Мульти-арендность. Одна копия приложения обслуживает много клиентов, данные изолированы.
• Единая кодовая база. Все клиенты пользуются одной версией приложения; обновления выкатываются централизованно.
• Самостоятельное подключение. Клиент сам регистрируется, выбирает тариф, оплачивает и начинает работать.
• Биллинг подписок. Регулярные списания, тарифные планы, фискальные чеки, повторные попытки списания.

Если хотя бы одно из требований не выполнено, у вас не SaaS-платформа, а заказное приложение с поддержкой. Это влияет на экономику: SaaS-компании оцениваются в 4-8 раз дороже проектных при той же выручке именно благодаря масштабируемой архитектуре.

Три подхода к мульти-арендности

1. Общая схема + row-level security (shared schema + RLS)

Все данные всех клиентов в одной базе и одной схеме. Каждая таблица помечена идентификатором арендатора (например, tenant_id). СУБД (PostgreSQL) на уровне политики безопасности (RLS) фильтрует выдачу по тому арендатору, который установлен в контексте сессии: SET app.current_tenant = '...'.

Плюсы:

• Самая дешёвая инфраструктура — один пул соединений на всех.
• Простая аналитика по всем клиентам — один SQL-запрос.
• Лёгкое обновление схемы — миграция выполняется один раз.
• Подходит для тысяч SMB-арендаторов.

Минусы:

• Утечка при ошибке в коде или RLS-политике — гипотетически возможна, нужна защита в нескольких слоях.
• Шумные соседи: один большой клиент может занимать ресурсы остальных.
• Бэкапы общие, восстановление по одному клиенту — отдельная процедура.

Когда выбирать: ваш сегмент — SMB, чек 1-30 тысяч ₽/мес, число клиентов до 5000, требований по физической изоляции нет.

2. Схема-на-арендатора (schema-per-tenant)

Одна база, но у каждого клиента своя PostgreSQL-схема. Названия таблиц одинаковые, доступ изолирован на уровне схемы.

Плюсы:

• Лучшая логическая изоляция: исключена утечка между схемами на уровне СУБД.
• Можно настраивать индексы и расширения отдельно для крупных клиентов.
• Удобнее отдавать бэкапы по запросу клиента.

Минусы:

• Миграции схемы должны прокатываться по всем схемам — N раз дольше.
• Пул соединений сложнее: переключение схемы на каждый запрос.
• Аналитика по всем клиентам требует UNION ALL по N схемам.

Когда выбирать: средний сегмент (чек 30-200 тысяч ₽/мес), 100-500 клиентов, есть требования к отдельным бэкапам или отдельной настройке производительности.

3. База-на-арендатора (database-per-tenant)

Отдельная база у каждого клиента. Максимальная изоляция: разные машины, разные сети, разные ключи шифрования.

Плюсы:

• Физическая изоляция данных и нагрузки.
• Отдельные бэкапы, отдельные SLA, отдельные ключи шифрования.
• Регуляторика отдельных клиентов (банки, ВПК, госорганы) обычно требует именно этого.

Минусы:

• Стоимость инфраструктуры растёт пропорционально числу клиентов.
• Обновление схемы — операция с N деплоями.
• Аналитика и кросс-арендаторные операции почти невозможны без отдельных ETL-процессов.

Когда выбирать: enterprise-сегмент (чек от 500 тысяч ₽/год), регуляторика, ВПК, банки. Чаще всего применяется как «hybrid» — основа SaaS на общей схеме, отдельные базы для самых крупных клиентов по запросу.

Сравнительная таблица подходов

Критерий	Общая схема + RLS	Схема-на-арендатора	База-на-арендатора
Стоимость инфры	низкая	средняя	высокая
Изоляция данных	логическая	сильная логическая	физическая
Сложность миграций	низкая	средняя	высокая
Аналитика по всем клиентам	простая	средняя	сложная
Бэкапы по клиенту	сложно	средне	просто
Потолок числа клиентов	5000+	500-1000	50-200
Подходит сегменту	SMB	SMB+средний	enterprise

Безопасность данных арендаторов

При мульти-арендной архитектуре безопасность строится в нескольких слоях:

1. Слой приложения. Каждый входящий запрос привязан к арендатору через JWT или сессию; middleware устанавливает контекст и отказывает в запросах без подтверждённого арендатора.
2. Слой СУБД. На общей схеме — row-level security, фильтр по tenant_id из переменной сессии. На схема-на-арендатора — разные search_path.
3. Слой данных. Чувствительные поля (пароли, токены, документы) шифруются с возможностью ротации ключей по арендатору.
4. Слой логирования. Все операции изменения логируются с tenant_id для аудита и восстановления.
5. Слой тестирования. Регулярные синтетические тесты на изоляцию: создаётся клиент A и клиент B, A пытается получить данные B, тест должен падать.

Для enterprise-клиентов с требованиями ИБ:

• Отдельная схема или БД.
• Отдельные ключи шифрования и отдельные бэкапы.
• Отдельные SLA на инциденты безопасности.
• Аттестация по 152-ФЗ или 187-ФЗ при необходимости.

Когда мигрировать с одного подхода на другой

Стандартный сценарий: вы стартуете на общей схеме + RLS, через 2-3 года приходит первый enterprise-клиент с требованием физической изоляции — переводите его в отдельную схему или БД. Через 5 лет основная масса SMB-клиентов остаётся на общей схеме, 5-10% enterprise живут на отдельных схемах.

Когда миграция нужна:

• Достигли потолка по числу клиентов или нагрузке.
• Регуляторика требует отдельных бэкапов или ключей.
• Шумные соседи мешают мелким клиентам.
• ИБ-отдел крупного клиента не подписывает договор без отдельной БД.

Стоимость миграции: 4-8 недель работы 2 senior-разработчиков на каждый шаг, плюс окно миграции по каждому клиенту. Поэтому архитектурное решение на старте важнее, чем кажется: правильный паттерн сэкономит 6-12 месяцев инженерных работ через 2-3 года.

Какой подход выбирать на старте

Для подавляющего большинства B2B SaaS-стартапов на российском рынке оптимальный старт — общая схема + row-level security с заложенным слоем абстракции для будущей миграции. Это значит:

• Все запросы к БД идут через слой репозиториев, которые получают tenant_id из контекста.
• Никаких хардкодных таблиц — всё через ORM с учётом RLS.
• Тесты на изоляцию — в CI с первого релиза.
• При появлении enterprise-клиента — точечная миграция в отдельную схему без переписывания приложения.

Подробнее об общей архитектуре SaaS — в гиде по разработке SaaS под ключ, о биллинговой части — в материале о приёме платежей онлайн.

Связанные архитектурные решения

Архитектура SaaS-платформы — это не только мульти-арендность. Сопутствующие решения:

• Тарифная модель и переключение между тарифами. Должна закладываться в архитектуру с первого релиза: одна таблица тарифов, привязка арендатора к тарифу, проверка лимитов в коде.
• Самостоятельное подключение и onboarding. Регистрация без участия менеджера, выбор тарифа, ввод платёжных данных, первое использование за 1-2 сессии.
• Биллинг и фискальные чеки. Подписки, рекуррент, ОФД-интеграция, dunning при сбоях списания — отдельный модуль архитектуры.
• Метрики и аналитика арендаторов. Каждое действие пользователя помечается tenant_id и записывается в аналитический слой (ClickHouse, BigQuery или внутренний data warehouse).
• Удержание клиентов как функция архитектуры. События активации, метрики использования, триггеры коммуникации — закладываются в продукт, а не приделываются сверху.

Что часто упускают при проектировании архитектуры SaaS

• Жёсткий хардкод одного арендатора. Когда продукт начинался как заказная разработка, а потом «переделывается в SaaS». Это всегда дороже, чем стартовать сразу с мульти-арендности.
• RLS без тестов. Политика безопасности живёт в SQL и легко ломается миграциями. Тесты на изоляцию — обязательны.
• Отсутствие плана миграции на отдельную базу. Когда придёт первый enterprise-клиент, вы должны быть готовы перевести его за 1-2 недели, а не за квартал.
• Игнорирование «шумных соседей». Без квот по ресурсам один большой клиент может сделать продукт неработоспособным для остальных. Закладывайте лимиты по запросам, объёмам данных и фоновым задачам.
• Аналитика поверх боевой схемы. Любые отчёты по всем арендаторам должны идти через отдельный аналитический слой, а не сожрать прод-базу.

Что дальше

Если вы проектируете архитектуру SaaS и колеблетесь между подходами — следующий шаг это предпроектное обследование с архитектором: 2-3 недели работы, на выходе техническое задание с выбранным паттерном мульти-арендности, диаграмма данных и схема миграции на будущее. Это даёт ясный план, который можно показать команде разработчиков и инвесторам.