Мультиарендность (Multi-Tenancy)

Мультиарендность (multi-tenancy) — это архитектурный паттерн, при котором один развёрнутый экземпляр приложения — одна кодовая база, часто одна база данных — обслуживает множество отдельных клиентов («арендаторов», tenants, обычно компаний или аккаунтов), данные каждого из которых должны быть изолированы от данных всех остальных, в противовес однотенантной (single-tenant) архитектуре, где каждый клиент получает полностью отдельное развёртывание. Почему это важно для разработчиков AI/SaaS-продуктов: практически любой B2B SaaS по необходимости мультиарендный — это единственный экономически жизнеспособный способ обслуживать тысячи клиентов без развёртывания и поддержки тысяч отдельных инфраструктурных стеков, — и неправильно выстроенная граница изоляции — одна из самых серьёзных ошибок, которую может допустить растущий SaaS, поскольку баг с утечкой данных между арендаторами часто катастрофичен (обращение в поддержку превращается в инцидент безопасности, корпоративная сделка — в судебный иск) в отличие от большинства других багов. AI-функции добавляют новую поверхность, где это может пойти не так: общий векторный индекс, общий слой кэширования промптов или общая дообученная модель могут случайно допустить утечку данных одного арендатора в результаты другого, если изоляция не обеспечивается на каждом уровне, а не только в основной реляционной базе данных. Как это работает: три распространённых паттерна в порядке возрастания изоляции и операционных затрат: общая база данных, общая схема (строки каждого арендатора живут в одних и тех же таблицах, различаясь только колонкой `tenant_id` — самый дешёвый в эксплуатации вариант, но изоляция полностью зависит от того, что каждый без исключения запрос корректно фильтрует по арендатору, без структурной страховки на случай, если разработчик забудет это сделать); общая база данных, отдельные схемы (каждый арендатор получает свою схему Postgres в рамках одной базы данных — более сильная изоляция, умеренные операционные затраты); и отдельная база данных на каждого арендатора (максимальная изоляция, самые высокие операционные затраты, обычно применяется для крупных корпоративных клиентов со строгими требованиями комплаенса). Row-level security (защита на уровне строк, функция Postgres) всё чаще используется, чтобы добавить страховку, обеспечиваемую самой базой данных, поверх паттерна с общей схемой — так что даже запрос, забывший условие `WHERE tenant_id = ?`, всё равно не сможет вернуть строки другого арендатора. Практический пример: AI CRM SaaS использует паттерн общей базы данных с общей схемой для реляционных данных (самый дешёвый вариант, отлично работающий при их текущем масштабе), но накладывает политики row-level security на каждую таблицу как структурную страховочную сетку, а также использует отдельные пространства имён (namespaces) на арендатора в векторной базе данных для AI-поиска контактов — а значит, баг, пропускающий фильтр `tenant_id` в реляционном или векторном запросе, всё равно не сможет привести к утечке данных, поскольку изоляция обеспечивается на уровне инфраструктуры, а не только в коде приложения, где будущий инженер может ошибиться.