В уходящем году мы запустили четыре B2B SaaS-проекта. У каждого свои особенности, но есть закономерности, которые проявляются на росте от 10 до 200 организаций. Об этих закономерностях - пост.
Изоляция данных: три варианта
- Shared schema, tenant_id в каждой строке - самый дешёвый вариант, начинают почти все.
- Schema per tenant - лучшая изоляция, проще аудит, сложнее миграции.
- Database per tenant - для крупных enterprise-клиентов, дорого в эксплуатации.
На 4 наших проектах все начинали с shared schema. Двое - остались на ней (масштаб 50–80 тенантов). Один переехал на schema per tenant после требования compliance. Один начал делать database per tenant для топ-3 enterprise-клиентов.
Роли и права
Простой RBAC выдерживает первые 30–50 тенантов. Дальше начинаются индивидуальные пожелания: «у этого клиента менеджер должен видеть отчёт, а у того - нет». Если не зарезервировать архитектурой возможность кастомизации - каждое такое пожелание становится feature-request.
Мы держим в правах три уровня: системные роли (admin/manager/viewer), tenant-специфичные оверрайды (можно отключить отдельную фичу для конкретной роли в конкретном тенанте), и feature flags (включить экспериментальную функцию у одного клиента).
Перформанс на больших таблицах
Главный сюрприз многих B2B-команд: query, который летал на тестовых данных 1000 строк, умирает на проде с 5 миллионами. Базовые правила: index на tenant_id всегда, partition по tenant_id для крупных таблиц, server-side pagination обязательно.
UI-нюансы
- Server-side фильтрация и сортировка - больших таблиц без них быть не может.
- Виртуальный скролл (react-virtual или TanStack Virtual) для списков от 500 строк.
- Saved views - пользователи устают каждый раз настраивать фильтры. Сохранённые представления - must-have от 50 тенантов.
- Экспорт в CSV/Excel - закладывайте сразу, у B2B-аудитории это базовое требование.
Биллинг и метрики
С первого дня закладывайте per-tenant метрики использования: сколько API-вызовов, сколько хранится данных, активные пользователи. Без этих чисел вы не сможете адекватно тарифицировать или предсказывать инфраструктурную нагрузку.