Мультитенантная маршрутизация для SaaS API
Тенанты по хосту, по пути и white-label ingress для B2B API — контекст клиента на шлюзе, без гигантских условных роутеров в каждой функции.
Обновлено: 2026-04-20
Кратко
Суть ответа
Мультитенантная маршрутизация для SaaS API. На API-Gateway задаёте, как из запроса получить tenant; в функцию уходит уже нормализованный контекст.
Когда подходит и когда нет
- B2B SaaS API
- Отдельные URL вебхуков на клиента
На что обратить внимание
- Один огромный роутер с вложенными if скрывает ошибки auth и усложняет ревью.
- Копировать одни и те же шаги деплоя под каждого клиента — плохо масштабируется.
Ситуация: нагрузка и где обычно ломается
Почему смешение клиентов обходится дорого
Если «кто клиент» проверяется наспех в одном стеке, выше риск перепутать ID и отдать чужие данные.
Без явного контекста клиента в запросе разбор инцидентов и логов затягивается.
Компромиссы
Что обычно идёт не так
Один огромный роутер с вложенными if скрывает ошибки auth и усложняет ревью.
Копировать одни и те же шаги деплоя под каждого клиента — плохо масштабируется.
Как Inquir помогает в этом сценарии
Как устроен приём трафика
На API-Gateway задаёте, как из запроса получить tenant; в функцию уходит уже нормализованный контекст.
Общие логи и секреты — без смешивания процессов разных клиентов в одном рантайме.
Что вы получаете на платформе
Паттерны мультитенантной маршрутизации
По домену
Поддомены клиентов ведут на нужный набор функций.
По префиксу пути
Один сертификат и отдельный неймспейс URL.
Разный auth
Разные политики API keys на разные поверхности при необходимости.
Что сделать дальше, по шагам
Как внедрить мультитенантную маршрутизацию
Выбрать стратегию
Отдельный домен — нагляднее для white-label; путь — когда DNS ограничен.
Прокинуть контекст
Явно передавайте идентификатор клиента в обработчики через событие шлюза.
Тестировать изоляцию
Автоматизируйте негативные сценарии: доступ клиента A к маршрутам B запрещён.
Пример кода
Маршрутизация по хосту и по пути
По хосту: acme.example.com → slug тенанта из заголовка Host. По пути: example.com/t/acme/api → slug из префикса URL. Оба паттерна нормализуют контекст до запуска обработчика.
export async function handler(event) { // acme.example.com → 'acme' const host = event.headers['host'] ?? event.headers['Host'] ?? ''; const tenantSlug = host.split('.')[0]; if (!tenantSlug) return { statusCode: 400, body: 'missing tenant' }; const payload = JSON.parse(event.body || '{}'); const data = await loadForTenant(tenantSlug, payload); return { statusCode: 200, body: JSON.stringify(data) }; }
export async function handler(event) { // /t/acme/api/orders → 'acme' const match = (event.rawPath ?? '').match(/^\/t\/([^/]+)/); const tenantSlug = match?.[1] ?? event.pathParameters?.tenant; if (!tenantSlug) return { statusCode: 400, body: 'missing tenant' }; const payload = JSON.parse(event.body || '{}'); const data = await loadForTenant(tenantSlug, payload); return { statusCode: 200, body: JSON.stringify(data) }; }
Когда подходит и когда нет
Когда это нужно
Когда это уместно
- B2B SaaS API
- Отдельные URL вебхуков на клиента
Когда лучше не трогать
- Один тенант и один продукт — достаточно простого роутинга
Вопросы и ответы
Вопросы и ответы
Это заменяет политики в базе данных?
Нет. Шлюз помогает не путать клиентов на входе; в БД всё равно нужны row-level правила и тесты.
Домен или префикс пути?
Домен проще для white-label API. Префикс — когда с DNS туго. В обоих случаях важно явно передавать tenant.
Как проверять изоляцию?
Негативные тесты: токен клиента A не должен работать на маршрутах B; в логах — стабильный тег клиента.