Продолжение базовой статьи
В первой части мы обозначили три модели. Здесь — как это влияет на миграции, биллинг и onboarding нового клиента.
Single database + tenant_id
Самый быстрый старт. Все таблицы с tenant_id, глобальные scope в моделях, middleware выставляет текущий tenant из поддомена или JWT.
Плюсы: одна миграция, простой деплой.
Минусы: риск утечки данных при ошибке в scope; тяжёлые клиенты делят ресурсы.
Используем пакеты вроде stancl/tenancy или собственный TenantContext — главное, тесты на изоляцию.
Отдельная БД на tenant
Максимальная изоляция для enterprise. Миграции гоняются по каждой БД, бэкапы отдельно.
Плюсы: compliance, масштабирование «тяжёлых» клиентов.
Минусы: операционная сложность, дольше provisioning.
Тарифы и feature flags
Тарифы лучше хранить в центральной БД, а feature flags (Pennant) — привязывать к tenant. Так можно включать модуль «отчёты» или «API» без ветвления кода на каждый план.
Onboarding нового клиента
Типовой flow: регистрация → создание tenant → seed ролей → welcome-данные → DNS/поддомен. Всё, что дольше 30 секунд, уводим в очередь с письмом «аккаунт готов».
Проектируете SaaS? Обсудим архитектуру — оценим модель tenant и сроки MVP.