ПостMulti Tenancy - это архитектурный подход в разработке, при котором один экземпляр приложения обслуживает множество разны…

Multi Tenancy - это архитектурный подход в разработке, при котором один экземпляр приложения обслуживает множество разных клиентов так, что они имеют доступ только строго к своим данным. Например, сервис для обслуживания компании, ведения проектов, изолированных воркспейсов и тд. Наверняка вы использовали такие в работе. От простого почтового сервера до CMS. Зайдя в одно окружение, юзер уверен что, увидит только свои данные. При этом физически все используют один и тот же хост и один процесс приложения, и часто одну и ту же базу данных. Плюсы такой архитектуры: ✅ юзеры использую одну и ту же инфраструктуру, то есть легче её поддержка. ✅ не нужно держать инфраструктуру активной для юзеров, которые не пользуются приложением. ✅ возможность связывать данные между клиентами (при определенных условиях). ✅ возможность хранить общие данные. Минусы: ❌ Очевидно - сложность реализации. Плюс разные особенности разных подходов к решению. Способ задать контекст, может быть реализован по-разному. Например, в Django есть приложение django.contrib.sites которое реализует разделение через домены. Это самая популярная техника. ▫️ Разделение по домену https://company1.my-app.com - домен для одной компании https://company2.my-app.com - домен для второй компании ▫️ Разделение по url https://my-app.com/client1/ https://my-app.com/client2/ ▫️ Определение ID на уровне хидера, выдаётся в момент аутентификации GET /api/v1/users HTTP/1.1 Host: api.myapp.com X-Tenant-ID: client-id ▫️ Сохранение в JWT, то есть сохраняется в токен как кастомный payload. Способ изоляции данных также имеет несколько решений. ▫️ разные БД ▫️ разные схемы в БД (не все СУБД поддерживают) ▫️ по FK-полям в общей схеме Каждый подход к разделению данных тоже имеет свои плюсы и минусы. Работает логика так: каждый запрос юзера на ранних этапах определяет контекст (в какой компании, проекте, воркспейсе находится юзер) и это влияет на то, какие настройки он подтягивает, как фильтруются запросы в БД. В следующем посте рассмотрим один практический пример на базе FastAPI #systemdesign