Архитектура multi-tenant SaaS

01Три модели мультитенантности

Представьте офисное здание. Общая схема — это open space: строки всех tenant'ов лежат в одних и тех же таблицах и разделяются колонкой tenant_id. Это самый дешёвый и простой в эксплуатации вариант — одна миграция для всех и лёгкая аналитика по всем tenant'ам, — но изоляция целиком зависит от того, ограничен ли каждый запрос. Schema-per-tenant — этаж с отдельными кабинетами: каждый tenant получает свой набор таблиц в одной базе. Изоляция сильнее, восстановить отдельного tenant'а проще, но миграции нужно прогонять по сотням или тысячам схем, а пулинг соединений усложняется. Database-per-tenant — отдельные здания: самая сильная изоляция, настройка производительности, размещение и ключи шифрования для каждого tenant'а, простое удаление — и самая высокая стоимость эксплуатации. Многие продукты их смешивают: общая схема для большинства tenant'ов и выделенные базы для крупных или регулируемых клиентов.

• Общая схема + tenant_id: дешевле всего, масштабируется на множество мелких tenant'ов, изоляция через код и RLS.
• Схема на tenant'а: золотая середина; главная боль — веерный прогон миграций.
• База на tenant'а: сильнейшая изоляция и локализация данных; самая высокая стоимость и нагрузка на эксплуатацию.

02Изоляция в несколько слоёв

Изоляция никогда не должна зависеть от того, вспомнит ли разработчик про условие WHERE. Определяйте tenant'а один раз на запрос из доверенного источника (аутентифицированный токен, API-ключ или поддомен), никогда — из поля в теле запроса, которое контролирует клиент. Храните его в контексте запроса и заставьте слой данных его применять: базовый класс репозитория, расширение ORM или глобальный scope, который добавляет фильтр по tenant'у и бросает исключение, если его нет. Добавьте второй, независимый слой в самой базе — row-level security в PostgreSQL, — чтобы даже забытый фильтр ничего не возвращал. Пусть ответом по умолчанию на ID другого tenant'а будет 404, а не 403, чтобы атакующие не могли выяснить, какие ID существуют. А затем докажите это тестами: каждый модуль получает тест «чужой tenant», который пытается прочитать и изменить записи другого tenant'а и ожидает отказа.

1ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
2ALTER TABLE orders FORCE ROW LEVEL SECURITY;
3 
4CREATE POLICY tenant_isolation ON orders
5  USING (tenant_id = current_setting('app.tenant_id', true)::uuid)
6  WITH CHECK (tenant_id = current_setting('app.tenant_id', true)::uuid);
7 
8-- Per request, inside a transaction, using a non-owner app role:
9BEGIN;
10SET LOCAL app.tenant_id = '00000000-0000-0000-0000-000000000001';
11SELECT id, total FROM orders;  -- only this tenant's rows
12COMMIT;

03Тарифы, лимиты и feature flag'и

Tenant'ы платят за разное, поэтому моделируйте права явно. Тариф определяет возможности (модули вроде лояльности или кухонных экранов) и лимиты (филиалы, пользователи, хранилище, вызовы API в минуту). Проверяйте возможности в одном месте — в политике или guard'е, — а не разбрасывайте «if plan === pro» по всему коду. Жёсткие лимиты применяйте при записи (создание одиннадцатого филиала падает с понятным сообщением), мягкие — через предупреждения и дашборды использования. Feature flag'и — отдельный инструмент: они постепенно включают функциональность для бета-tenant'ов, дают аварийные выключатели и позволяют делать индивидуальные исключения для tenant'ов, согласованные в сделках отдела продаж. Делайте и то и другое прозрачным для аудита, потому что «почему этот tenant может это делать?» — вопрос, который поддержка точно услышит. Точный учёт использования нужен и для биллинга, поэтому записывайте его событиями, а не пересчитывайте по живым таблицам.

04Кэширование, очереди и realtime с учётом tenant'а

Каждый общий компонент — место, где tenant'ы могут «протечь» друг к другу. Ключи кэша должны включать ID tenant'а (tenant:42:menu:v3), иначе одно кафе увидит меню другого. Фоновые задачи должны нести ID tenant'а в своих данных, а воркер должен восстановить контекст tenant'а, прежде чем трогать данные, — ровно так же, как это сделал бы запрос. Realtime-каналы требуют той же аккуратности: подписывайте клиентов на комнаты по tenant'у и по филиалу и авторизуйте каждую подписку на сервере. Файлы кладите по путям с префиксом tenant'а в объектном хранилище и отдавайте через короткоживущие подписанные URL. Логи и трейсы должны включать ID tenant'а, чтобы поддержка могла разбираться с одним клиентом, не просматривая всех. И наконец, rate limit'ы и параллелизм очередей должны быть на уровне tenant'а, чтобы импорт одного tenant'а не мог заморить голодом остальных.

• Имена ключей кэша, путей в хранилище и каналов всегда включают tenant'а.
• Задачи восстанавливают контекст tenant'а перед запуском.
• Rate limit'ы по tenant'ам и справедливые очереди против шумных соседей.

05Шумные соседи, экспорт и удаление данных

В общей системе один tenant, запустивший огромный отчёт или импорт, может замедлить всех. Защищайте остальных rate limit'ами и квотами по tenant'ам, statement timeout'ами для запросов, отдельными очередями или ограничением параллелизма для тяжёлых задач и переносом тяжёлой работы на непиковые часы. Следите за потреблением ресурсов каждым tenant'ом, чтобы замечать выбросы, и при необходимости переносите очень крупных tenant'ов на выделенные ресурсы — это одна из причин сохранять способность слоя данных направлять tenant'а в другую базу. Кроме того, tenant'ы владеют своими данными. Предложите полный экспорт в задокументированных форматах (CSV, JSON) и реализуйте удаление как настоящий процесс: мягкое удаление на льготный период, затем окончательное удаление из базы, файлов, кэшей и поисковых индексов, а бэкапы истекают по известному графику. Задокументируйте это для запросов в духе GDPR.

06Клиенты с офлайн-режимом и синхронизация

Кассовые терминалы, полевые приложения и киоски должны продолжать работать, когда пропадает интернет. Паттерн такой: клиент или локальный хаб держит локальную базу (часто SQLite) с нужными ему данными, записывает каждое изменение как команду с уникальным ID и отправляет эти команды на сервер, когда соединение возвращается. Сервер применяет каждую команду идемпотентно, дедуплицируя по ID команды и устройству, так что повторы после нестабильных переподключений безопасны. Правила разрешения конфликтов определяйте для каждой сущности: записи, которые только дописываются, вроде продаж, конфликтуют редко; общим записям вроде остатков или цен нужен понятный владелец, правило «сервер прав» или явное слияние. Аккуратно версионируйте локальную схему и миграции, потому что устройства обновляются в разное время. Давайте офлайн-устройству только те права и данные, которые нужны его филиалу, и используйте привязанные к устройству токены, которые можно отозвать.

07Row-level security в продакшене: пулинг, производительность и роли

SET LOCAL не принимает bind-параметры, поэтому многие приложения собирают запрос строкой. Безопаснее использовать set_config('app.tenant_id', $1, true), где true означает «локально для этой транзакции»: так работают и параметры, и пулеры в transaction-режиме. В политиках используйте форму current_setting с missing_ok, чтобы незаданное значение давало NULL, которому не соответствует ни одна строка, а не ошибку. Производительность: политики добавляют условие в каждый запрос, поэтому ставьте tenant_id первым в составных индексах (tenant_id, created_at) и в уникальных ограничениях (tenant_id, slug). Функции, вызываемые внутри политик, должны быть простыми и STABLE; сложные подзапросы на каждую строку медленные. Используйте три роли: роль миграций, владеющую таблицами, роль приложения без BYPASSRLS и отдельную аудируемую роль обслуживания для настоящих межтенантных задач.

1-- Inside each request transaction (works with bind parameters and poolers)
2SELECT set_config('app.tenant_id', $1, true);
3 
4-- Indexes and constraints lead with the tenant
5CREATE INDEX orders_tenant_created_idx ON orders (tenant_id, created_at DESC);
6ALTER TABLE products ADD CONSTRAINT products_tenant_sku_key UNIQUE (tenant_id, sku);
7 
8-- App role cannot bypass policies
9CREATE ROLE app_rw LOGIN NOBYPASSRLS;
10GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_rw;

08Маршрутизация тенантов: tenant directory, ячейки и размещение

Держите tenant directory — небольшую высокодоступную таблицу или сервис, который сопоставляет каждого тенанта с местом, где лежат его данные: общий кластер A, выделенная база B, регион EU. Каждый запрос определяет тенанта, затем его размещение и подключается к нужному пулу. Этот один уровень косвенности делает возможными будущие переезды: перенесите крупного тенанта в собственную базу, скопировав данные, проиграв изменения, ненадолго заморозив записи и переключив запись в справочнике. Если пойти дальше, cell-based архитектура запускает несколько одинаковых стеков (приложение, база, кэш, очереди), каждый из которых обслуживает подмножество тенантов. Тогда неудачный деплой или перегрузка затрагивает одну ячейку, а не всех клиентов, и изменения раскатываются ячейка за ячейкой. Цена — больше инфраструктуры и инструментов для межъячеечных операций вроде глобального поиска в админке и биллинга, поэтому большинство продуктов начинают с одной ячейки и справочника, готового к расширению.

09Миграции и изменения схемы для множества тенантов

В общей схеме одна миграция сразу затрагивает данные всех тенантов, поэтому она должна быть online: добавляйте колонки nullable или с константным default, создавайте индексы CONCURRENTLY, делайте backfill небольшими батчами, затем добавляйте ограничения как NOT VALID и валидируйте отдельно. Никогда не блокируйте нагруженную таблицу на минуты. При schema-per-tenant или database-per-tenant проблема превращается в fan-out: тысячи миграций, которые могут частично упасть. Запускайте их через job runner со статусом по каждому тенанту, ретраями и лимитами параллелизма, держите приложение совместимым и со старой, и с новой схемой на время раскатки (expand, migrate, contract) и сделайте остановку на полпути безопасной. Отслеживайте версию схемы для каждого тенанта и отказывайтесь обслуживать тенанта, чью версию работающий код не поддерживает.

• Сначала expand, затем деплой кода, работающего с обеими схемами, contract — позже.
• CREATE INDEX CONCURRENTLY и backfill батчами для больших таблиц.
• Статус миграции по тенантам для конфигураций schema- или database-per-tenant.

10Внутренности офлайн-синхронизации: порядок, часы и конфликты

Часы устройств расходятся, поэтому одних wall-clock меток времени недостаточно, чтобы упорядочить изменения с нескольких устройств. Распространённые подходы: пусть сервер присваивает монотонно растущий порядковый номер при приёме команды, а клиенты забирают «всё после номера N»; или используйте hybrid logical clock, которые сочетают физическое время со счётчиком, оставаясь близкими к реальному времени и сохраняя причинность. Для конфликтов выбирайте правило для каждого поля: события только на дописывание никогда не конфликтуют; last-writer-wins прост, но молча теряет правки; слияние на уровне полей сохраняет непересекающиеся изменения; CRDT сливают счётчики, множества и текст автоматически ценой сложности. Делайте команды маленькими и основанными на намерении («добавить 2 единицы в заказ 15»), а не перезаписью всего состояния — они сливаются гораздо лучше. Ограничьте, сколько устройство может оставаться офлайн, прежде чем ему потребуется полная пересинхронизация.