Мультитенантный (multi-tenant) SaaS снаружи выглядит как одно приложение; внутри же это дисциплина переноса данных тысяч компаний на одном ядре так, чтобы они никогда не соприкасались. Это неизменная тема и инженерного вебинара, который Corex360 проводит каждый месяц: как построить систему с единой кодовой базой, единой инфраструктурой, но при этом дающую каждому арендатору ощущение собственного мира.
Изоляция: схема или строка?
Первое и самое критичное решение — это изоляция данных. Есть два основных подхода: отдельная схема для каждого арендатора (schema-per-tenant) или маркировка каждой строки в общих таблицах с помощью tenant_id (row-level). Подход на основе схем даёт сильное физическое разделение и простое резервное копирование, но управление десятками тысяч схем утяжеляет миграции. Построчный подход операционно легче и масштабируется; однако одно недостающее условие WHERE — это катастрофа. На практике побеждает гибрид: построчная изоляция для большинства модулей + политики безопасности на уровне строк (RLS), принудительно применяемые на уровне базы данных, а для крупных корпоративных арендаторов — логическое разделение.
Главное — обеспечивать изоляцию не полагаясь на код приложения, а принудительно на самом низком возможном уровне. Разработчик, который однажды забудет вручную добавить фильтр tenant_id в каждый запрос, в один прекрасный день сольёт данные другого арендатора. Поэтому фильтр встраивается в политику базы данных и в общий слой запросов; даже если разработчик захочет его обойти, он не сможет.
В мультитенантной архитектуре безопасность — не функция, а поведение по умолчанию; не исключение, а правило.
Единое ядро, синхронизация в реальном времени
В Corex360 сообщение, упавшее из WhatsApp, должно одновременно появиться во входящем ящике, в карточке CRM и на BI-панели. Мы решаем это не постоянным опросом каждого экрана, а событийным (event-driven) каркасом: когда что-то происходит — новое сообщение, выставленный счёт, движущаяся машина — система публикует событие, соответствующие модули его слушают и обновляют себя. Даже когда единое ядро обслуживает тысячи арендаторов, события каждого арендатора циркулируют только в пределах его собственных границ.
Эта архитектура держит модули слабо связанными друг с другом. Модулю контроля транспорта не обязательно знать внутреннее устройство складского модуля; оба говорят на одном языке событий. Добавить новый модуль — значит не переписать ядро, а добавить в поток нового слушателя. Секрет масштабирования — в управлении не размером, а независимостью.
Права на уровне арендатора и KVKK/GDPR
В Турции — KVKK, в Европе — GDPR; оба требуют чёткого ответа на вопрос «кому принадлежат данные и кто может их видеть». В мультитенантной системе это означает двухуровневую авторизацию: сначала граница арендатора (пользователь одной компании никогда не получит доступ к данным другой компании), затем роли внутри арендатора (руководитель полевой бригады видит данные о транспорте, бухгалтер — счета, но не все видят всё).
Практическая сторона соответствия — это проверяемость: кто, когда и к каким данным получал доступ; при запросе на удаление данных арендатора действительно и только следы этого арендатора удаляются; возможность применять сроки хранения данных на уровне арендатора. Хорошая мультитенантная архитектура несёт KVKK не как слой соответствия, приклеенный задним числом, а как естественное следствие решения об изоляции.
