SaaS-продукт легко начать и тяжело масштабировать. Первая версия для десяти клиентов пишется быстро, а вот когда клиентов становится тысячи, а среди них появляются крупные с особыми требованиями к изоляции данных, гибкими тарифами и нагрузкой, всплывают решения, принятые на старте «как получится». Переписывать архитектуру работающего продукта — самый дорогой вид технического долга.
Разберём три опоры, на которых стоит любой зрелый SaaS: мультитенантность, биллинг и масштабирование. По каждой покажем развилки и дадим ориентиры, как выбрать так, чтобы продукт рос, а не упирался в потолок.
Мультитенантность: три модели изоляции данных
Мультитенантность — это то, как данные разных клиентов (тенантов) сосуществуют в одной системе. Это самое фундаментальное решение SaaS, и менять его потом мучительно.
Shared database, shared schema
Все тенанты в одной базе и одних таблицах, разделение по полю tenant_id. Максимально экономно по ресурсам, проще всего масштабируется по числу клиентов, легко выкатывать обновления. Минус — изоляция логическая, а не физическая: ошибка в коде или запросе теоретически может смешать данные, и требуется дисциплина на уровне каждого запроса.
Shared database, separate schema
Одна база, но у каждого тенанта своя схема. Компромисс: лучше изоляция, проще выгрузить или удалить данные конкретного клиента, но сложнее администрировать тысячи схем и мигрировать их.
Database per tenant
Отдельная база на каждого тенанта. Максимальная изоляция, проще требования по безопасности и резервному копированию по клиенту, легко вынести крупного клиента на отдельные ресурсы. Минус — дороже и сложнее в эксплуатации, миграции нужно прогонять по всем базам.
На практике зрелые SaaS часто комбинируют: основная масса клиентов живёт в shared-модели, а крупные enterprise-клиенты выносятся в отдельные базы. Архитектуру стоит сразу проектировать так, чтобы такой переезд был возможен.
Выбор модели — ключевая задача на этапе проектирования SaaS-продукта, и здесь экономия на проектировании оборачивается самыми дорогими ошибками.
Как выбрать модель мультитенантности
Решение опирается не на «как модно», а на требования к данным и клиентам.
- Жёсткие требования к изоляции и комплаенсу (медицина, финансы) — склоняйтесь к separate schema или database per tenant.
- Массовый продукт с тысячами мелких клиентов — shared schema ради экономики.
- Смешанная база: и SMB, и enterprise — гибридная модель с возможностью выноса крупных клиентов.
- Требование «удалить все данные клиента по запросу» — проще там, где данные физически разделены.
В основе данных у большинства наших SaaS-проектов — PostgreSQL с отказоустойчивым кластером на Patroni, что даёт надёжную базу для любой из моделей и для роста нагрузки.
Биллинг: сердце экономики продукта
Биллинг кажется второстепенным, пока продукт маленький. На росте он становится одной из самых сложных подсистем, потому что напрямую завязан на деньги, и ошибки здесь видны сразу.
Что должен уметь биллинг зрелого SaaS
- Гибкие тарифные планы: подписки, лимиты, пакеты, переходы между тарифами.
- Учёт потребления (usage-based): оплата за использованные ресурсы, API-вызовы, места.
- Пропорциональные начисления (proration) при смене тарифа в середине периода.
- Промокоды, скидки, триалы, грейс-периоды.
- Работа с неудачными платежами: повторные попытки, уведомления, мягкая и жёсткая блокировка.
- Документы и интеграция с платёжными провайдерами и бухгалтерией.
Главный совет — не размазывать биллинговую логику по всему приложению. Это должен быть выделенный, хорошо изолированный домен с чёткими границами. Иначе изменение тарифной политики превращается в правку десятков мест и источник багов, каждый из которых стоит реальных денег.
Масштабирование: горизонталь с самого начала
Третья опора — способность расти под нагрузкой. Ключевой принцип: проектировать под горизонтальное масштабирование, даже если на старте хватает одного сервера.
Stateless-приложение
Сервисы не должны хранить состояние в памяти процесса. Сессии, кэш, очереди выносятся наружу (Redis, брокеры сообщений). Тогда добавить ещё один инстанс под нагрузкой — это вопрос конфигурации, а не переписывания.
База как узкое место
Чаще всего упирается именно база. Инструменты: чтение с реплик, отказоустойчивый кластер на Patroni, продуманные индексы, кэширование тяжёлых запросов в Redis, а для поиска и AI-функций — векторная база Qdrant. Для самых нагруженных частей оправдан вынос в отдельные сервисы, в том числе на Go.
Фоновая обработка
Всё, что можно сделать асинхронно — отчёты, уведомления, экспорт, тяжёлые вычисления — выносится в очереди и воркеры, чтобы не блокировать пользовательские запросы.
Инфраструктурно это упаковывается в Docker и оркестрируется Kubernetes, что даёт предсказуемое масштабирование и отказоустойчивость. Для продуктов уровня высоконагруженных систем это не опция, а необходимость.
Наблюдаемость: вы не управляете тем, что не видите
SaaS, который масштабируется вслепую, рано или поздно падает в самый неподходящий момент. Наблюдаемость — обязательная часть архитектуры, а не «допилим потом».
- Метрики: нагрузка, время отклика, потребление ресурсов по сервисам и по тенантам.
- Логи: централизованные, с контекстом тенанта и запроса.
- Трейсинг: сквозное прослеживание запроса через сервисы.
- Алертинг: проблема видна до того, как о ней сообщит клиент.
Отдельно важна наблюдаемость в разрезе тенантов: один «тяжёлый» клиент не должен незаметно деградировать сервис для всех остальных.
Безопасность мультитенантной системы
В SaaS цена ошибки изоляции — это утечка данных одного клиента другому, что для B2B-продукта означает потерю доверия и контракта. Поэтому безопасность встраивается в архитектуру.
- Tenant_id проверяется централизованно, а не в каждом запросе вручную.
- Разграничение доступа по ролям внутри тенанта.
- Шифрование чувствительных данных, изоляция секретов.
- Аудит действий и доступов.
Эти механизмы дешевле заложить на старте, чем встраивать в работающий продукт под давлением инцидента.
Типичные ошибки старта
Самые дорогие решения SaaS принимаются в первые месяцы. Вот те, что чаще всего приходится исправлять переписыванием.
- Никакой мультитенантности «пока». Tenant_id прикручивают позже — и это всегда болезненно.
- Stateful-приложение, которое нельзя масштабировать горизонтально.
- Биллинг, размазанный по коду, вместо изолированного домена.
- Отсутствие наблюдаемости, из-за чего рост превращается в гадание.
Мини-вывод
Зрелый SaaS стоит на трёх опорах. Мультитенантность определяет, как изолированы данные клиентов, и выбирается под требования к безопасности и профиль клиентской базы. Биллинг должен быть выделенным доменом, готовым к гибким тарифам и usage-based-модели. Масштабирование закладывается через stateless-сервисы, продуманную работу с базой и горизонтальный рост. Всё это поддерживается наблюдаемостью и безопасностью с первого дня.
Эти решения определяют, будет ли продукт расти органично или упрётся в дорогую переделку. Мы проектируем архитектуру SaaS под ваш сценарий роста — от выбора модели мультитенантности до стратегии масштабирования. Обсудите проект с нами, пока эти решения ещё ничего не стоят исправить.
