Мультитенантная маршрутизация для SaaS API
Тенанты по хосту, по пути и white-label ingress для B2B API: контекст клиента определяется на шлюзе — без гигантских условных роутеров в каждой функции.
Обновлено: 2026-06-28
Кратко
Суть ответа
Мультитенантная маршрутизация для SaaS API. На API-шлюзе задаёте, как извлекать тенанта из запроса, — в функцию приходит уже нормализованный контекст, и обработчикам не нужно выводить его из сырых запросов.
Когда подходит и когда нет
- B2B SaaS API
- Отдельные URL вебхуков на клиента
На что обратить внимание
- Один огромный роутер с вложенными if прячет ошибки auth до тех пор, пока их не найдёт инцидент.
- Копировать деплой под каждого клиента — плохо масштабируется уже после первого десятка тенантов.
Ситуация: нагрузка и где обычно ломается
Почему смешение клиентов обходится дорого
Если «кто клиент» проверяется наспех в одном общем стеке, легко перепутать ID — а в B2B API перепутанный ID означает утечку чужих данных.
Без явного контекста клиента в запросе разбор инцидентов и логов затягивается ровно в тот момент, когда время дороже всего.
Компромиссы
Каких анти-паттернов избегать
Один огромный роутер с вложенными if прячет ошибки auth до тех пор, пока их не найдёт инцидент.
Копировать деплой под каждого клиента — плохо масштабируется уже после первого десятка тенантов.
Как Inquir помогает в этом сценарии
Структурированный вход для мультитенантных API
На API-шлюзе задаёте, как извлекать тенанта из запроса, — в функцию приходит уже нормализованный контекст, и обработчикам не нужно выводить его из сырых запросов.
Наблюдаемость и конфигурация переиспользуются между тенантами — без смешивания их процессов в одном рантайме.
Что вы получаете на платформе
Паттерны мультитенантной маршрутизации
По домену
Поддомены клиентов ведут на нужный набор функций.
По префиксу пути
Один сертификат и отдельный неймспейс URL для каждого клиента.
Разный auth
Разные политики API-ключей на разные поверхности, когда это нужно.
Что сделать дальше, по шагам
Как внедрить мультитенантную маршрутизацию
Выбрать стратегию
Отдельный хост нагляднее для 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 ?? event.path ?? '').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 туго. Оба варианта рабочие, если контекст тенанта явно передаётся в обработчики.
Как проверять изоляцию?
Негативными тестами: токен клиента A не должен работать на маршрутах клиента B, а в логах должен быть стабильный тег тенанта.