Ошибки проектирования мультиарендных систем, приводящие к дорогостоящим переработкам

Почему это потом дорого обходится

Первая версия мультиарендного продукта часто выглядит безобидно. Одна база данных, одна схема, один набор фоновых задач и tenant ID в каждой строке. Это быстро выпускается, и при небольшой базе клиентов работает достаточно хорошо.

Проблема начинается, когда этот ранний выбор проникает во всё остальное. Доступ к данным, правила входа, лимиты запросов, отчётность, биллинг, инструменты поддержки, кэши и аудиторские логи — всё зависит от одной общей модели. Если модель рыхлая, вы не исправите одну ошибку позже — придётся трогать половину продукта.

Вот почему ошибки в дизайне мультиарендности становятся дорогими. Ловкий «чек‑поинт» в хранилище протекает в авторизацию. Ловкий «чек‑поинт» в авторизации протекает в биллинг. Если приложение не может чётко ответить «кто владеет этими данными, кто может с ними действовать и кто платит за это использование», рефакторинг не останется небольшим.

Рост делает слабые места очевидными. Тесты обычно используют аккуратные тестовые данные, несколько пользователей и предсказуемый трафик. Реальные клиенты делают наоборот. Один тенант импортирует 2 миллиона записей. Другой запускает отчёты каждый час. Третий требует жёстких правил доступа для подрядчиков, админов и финансовой команды. Продукт, который выглядел нормально с десятью тенантами, начинает прогибаться в местах, которые тесты не трогали.

Отказы обычно простые:

• утечка данных между тенантами
• один тенант замедляет всех остальных
• пользователи видят или изменяют то, что вне их области

Небольшой пример показывает стоимость. Вы начинаете с общих таблиц и фильтров на уровне приложения. Через шесть месяцев корпоративный клиент просит отдельный биллинг, более строгие аудиторские логи и лимиты, которые применяются только к их рабочей области. Теперь нужно менять запросы, задания, права, счета и админ‑инструменты одновременно.

Вот почему такие переработки больно бьют. Проблема не в одной плохой таблице или в одном небрежном проверочном условии. Проблема в форме системы, поэтому любое исправление расходится по всему продукту.

Решите, что значит «тенант»

Многие проблемы начинаются с одного неясного слова: «тенант». Если команда использует «тенант», «пользователь», «рабочее пространство» и «организация» как синонимы, схема быстро размазывается. Тогда биллинг, права и отчётность начинают тянуть в разные стороны.

Выберите простые определения как можно раньше. Пользователь — обычно человек с логином. Организация — бизнес, который платит. Рабочее пространство — место, где люди выполняют работу. Тенант может быть организацией или может быть каждым рабочим пространством. Любая модель может работать, но в продукте должна быть только одна истина.

Этот выбор влияет почти на каждую таблицу, которую вы создаёте. Кто владеет проектом? Кто владеет загруженными файлами? Где хранятся feature flags? Если налоговые настройки, брендинг и история счетов принадлежат платящей компании — привязывайте их к компании. Если доски задач или документы принадлежат отдельным командам внутри компании — привязывайте их к рабочему пространству.

Членство тоже требует ясности. Многие продукты предполагают, что пользователь принадлежит одному тенанту, потому что так проще на старте. Позже консультант, партнёр‑агенство или админ материнской компании может понадобиться доступ к нескольким тенантам, и модель авторизации начнёт трещать. Если такой сценарий даже немного вероятен, поддерживайте many‑to‑many членство с самого начала.

Несколько правил сэкономят много боли позже:

• биллинг принадлежит платящей сущности
• владение данными и области применимости прав — разные вещи
• настройки должны жить там, где они реально меняются
• пользователи могут понадобиться в нескольких тенантах

Если у одного клиента пять региональных команд с разными данными, но одной общей счёт‑фактурой, ваша модель должна это поддерживать без костылей. Если не поддерживает — миграция попадёт в авторизацию, биллинг, API и каждую админ‑страницу.

Проведите линии изоляции рано

Самые дорогие исправления часто начинаются с одной плохой догадки: «мы добавим правила тенанта позже». Это редко остаётся небольшим. Как только данные разойдутся по кэшу, файлам, поиску и заданиям, очистка превращается в проект миграции.

Граница тенанта должна существовать в первой точке, где ваше приложение читает или записывает данные. Если запрос доходит до кода без привязанного контекста тенанта, кто‑то забудет фильтр. Тогда один отчёт, один API‑эндпоинт или одна админ‑страница вытечет данные между аккаунтами.

Держите эту границу согласованной везде, где хранятся данные: запросы к базе, пути в объектном хранилище, ключи кэша, индексы поиска, сообщения в очередях, логи, экспорты и бэкапы. Общая инфраструктура — ок. Общие записи без явного контекста тенанта — нет.

Фоновая работа подчиняется тем же правилам. Сообщения в очереди, cron‑задачи, дайджесты по e‑mail, биллинговые прогоны и задачи синхронизации должны нести tenant ID в полезной нагрузке. Не позволяйте воркеру догадываться позднее из расплывчатого контекста. Так одна задача по очистке удаляет файлы другого тенанта.

Логи, экспорты и бэкапы обычно игнорируют до запроса аудита или удаления данных. Если логи смешивают тенанты в одних и тех же полях — поддержка становится рискованной. Если экспорты запускаются из несфокусированных запросов — кто‑то отправит неправильный CSV. Бэкапы требуют того же внимания. Если одному клиенту нужно восстановление, вы должны уметь восстановить только его данные.

Простой тест работает хорошо: выберите один тенант и проследите запрос от входа до хранилища, поиска и бэкапа. Если в какой‑то момент контекст тенанта исчезает — исправьте дизайн до запуска.

Планируйте «noisy neighbors»

Один большой тенант может замедлить всех остальных задолго до того, как графики станут страшными. Первая версия часто работает нормально с небольшими аккуратными нагрузками, поэтому команды думают, что дизайн безопасен.

Начните с перечисления всех общих ресурсов, которые один тенант может заполнить. Команды обычно думают о CPU и нагрузке на базу, а потом забывают про менее очевидные ограничения, которые падают первыми: соединения с БД, долгие запросы, очереди воркеров, место в кэше, квоты третьих сторон, пропускная способность почты, обработка файлов и индексирование поиска.

Простое правило помогает: интерактивный трафик и пакетная работа не должны конкурировать за один путь. Если один клиент запускает огромный импорт, обычные страницы, маленькие записи и запросы на вход должны продолжать работать. Поместите импорты, экспорты, backfill и большие синк‑задачи в отдельные очереди. Дайте пользовательской работе более высокий приоритет и установите лимиты по тенанту, чтобы один аккаунт не мог заполнить всю очередь.

Лимиты частоты важны и внутри системы, не только на публичном API. Ограничьте, сколько задач тенант может поставить в очередь, сколько воркеров он может занять и сколько параллельной работы он может инициировать одновременно. Если вы работаете экономно с инфраструктурой, это важно ещё больше. Один активный клиент может съесть запасную ёмкость за минуты.

Отслеживайте поведение по отдельным тенантам. Общая задержка может выглядеть здоровой, в то время как один клиент страдает таймаутами или в коротких всплесках вредит всем остальным. Отслеживайте скорость запросов, глубину очереди, время выполнения задач, процент ошибок и p95‑латентность по тенанту. Когда тенант превышает лимит — оповещайте именно по этому тенанту, а не только по всему сервису.

Распространённая ошибка сначала кажется мелкой. Клиент загружает 500 000 строк, воркеры блокируют таблицы, кэш частично сбрасывается, повторные отправки писем накапливаются, а служба поддержки получает расплывчатые жалобы на медленную работу. Проектирование очередей и ограничения по тенантам гораздо дешевле, чем исправлять это после того, как ваш крупнейший клиент зависит от плохого поведения.

Установите границы авторизации с первого дня

Большинство утечек тенантов не начинается в базе данных. Они начинаются в коде авторизации, который считает «вошёл в систему» эквивалентным «может видеть этот аккаунт».

Каждый запрос должен нести контекст тенанта, и сервер должен проверять его до чтения или записи. Не доверяйте tenant ID из браузера. Проверьте, что пользователь принадлежит этому тенанту, что его роль применима в этом тенанте и что действие соответствует обоим условиям.

Роли безопаснее, когда они локальны для тенанта. «Admin» должен означать админа тенанта A, а не админа всех клиентов в системе. Глобальные админы иногда нужны, но держите их редкими, явными и легко проверяемыми.

Самые опасные крайние случаи делают наибольший вред. Ссылка‑приглашение должна знать, к какому тенанту она относится. Сброс пароля должен вернуть пользователя в правильный поток тенанта. API‑токен должен нести область действия тенанта, а не только пользователя, иначе один скрипт может читать данные чужого аккаунта.

Короткий чек‑лист помогает:

• проверяйте членство в тенанте на каждом запросе, включая внутренние API и фоновые задания
• храните роли в записи членства, а не только в записи пользователя
• ограничьте приглашения, потоки сброса, сессии и токены одним тенантом
• тестируйте инструменты поддержки реальными задачами сотрудников, а не только чистым демо‑путём

Инструментам поддержки нужно дополнительное внимание. Часто внутри создают дашборд, который пропускает те же проверки, что и основное приложение. Тогда сотрудник поддержки ищет по e‑mail, открывает первый результат и попадает в чужой тенант.

Боль обычно проявляется позже, когда вы добавляете SSO, аудиторские логи, возможность имперсонации или у вас появляются крупные клиенты, которые спрашивают, кто может что видеть. Исправление границ авторизации поздно означает менять маршруты, задания, токены и админ‑экран одновременно.

Выбирайте ID и модели данных аккуратно

Плохой выбор идентификаторов остаётся незаметным месяцами. Потом один клиент меняет имя компании, другой хочет объединить два аккаунта, а третий просит разделить рабочее пространство на два. Если записи зависят только от e‑mail, субдомена или названия аккаунта, простая просьба превращается в рискованную миграцию.

Используйте стабильные внутренние ID для тенантов, пользователей, проектов и каждой записи, которая может жить долго. Рассматривайте имена и e‑mail как атрибуты, а не как идентичность. Люди меняют e‑mail. Компании ребрендятся. Команды переименовывают продукты — это нормально.

Правила уникальности должны иметь область тенанта, когда значение важно только внутри одного тенанта. Код проекта вроде «sales» может существовать в разных тенантах без проблем. То же касается имён пользователей, имён папок и тегов. Если вы по ошибке делаете эти значения глобальными, второй клиент, который захочет такое же имя, упирается в стену.

Небольшой пример быстро показывает проблему. Тенант A создаёт пользователя с [email protected]. Позже тенант B приобретает часть бизнеса и хочет того же человека в новом тенанте. Если модель считает e‑mail идентификатором пользователя, у вас одна идентичность пытается соответствовать двум правилам владения. Если вы разделяете идентичность пользователя и членство в тенанте, перенос проходит намного чище.

Планируйте неловкие случаи заранее. Один тенант может перенести данные другому. Два тенанта могут объединиться. Один тенант может разделиться на бизнес‑единицы. Запись может сменить владельца, но сохранить историю.

Здесь важны аудиторские следы. Когда меняется владение, сохраняйте старый тенант, новый тенант, кто одобрил перенос и когда это произошло. По возможности сохраняйте исходный ID записи и логируйте трансфер как событие. Это упрощает отчёты, поддержку и проверки прав позже.

Проверьте дизайн на одной реальной операции

Проблемы остаются скрытыми, пока вы не проследите одну реальную операцию через всё приложение. Диаграмма помогает, но живой прогон лучше. Вам нужно увидеть, где появляется контекст тенанта, где код ему доверяет и где этот контекст может исчезнуть.

Начните с входа. Отметьте, как приложение решает, кто пользователь и к какому тенанту он принадлежит. Затем проследите тот же запрос через API‑слой, фоновые задания, кэш, запросы в базу, файловое хранилище и любые очереди событий.

Запишите каждое место, где код читает контекст тенанта. Некоторые команды берут его из сессии в одном эндпоинте, из JWT‑полей в другом и из заголовка запроса где‑то ещё. Такая разнотолкованность создаёт баги, потому что один пропущенный чек может раскрыть данные другого тенанта.

Во время ревью проследите одно действие от входа до записи в базу, например создание счёта или обновление проекта. Проверьте каждый запрос на явный фильтр по тенанту, а не на допущение, спрятанное в коде приложения. Запустите одного тяжёлого тенанта рядом с множеством маленьких и наблюдайте времена отклика, задержки в очередях и лимиты. Затем проверьте экспорты, вебхуки, бэкапы и скрипты восстановления на предмет смешивания данных клиентов.

Экспорты и бэкапы заслуживают отдельного внимания, потому что они часто находятся вне основного потока запросов. Команда может защитить само приложение, но забыть, что задача на CSV собирает строки из нескольких тенантов в один файл, или что скрипт восстановления загружает данные не в тот аккаунт после инцидента.

Noisy neighbors тоже проявляются на ревью, а не в счастливом тестировании. Один большой тенант может заполнить общую очередь, держать блокировки в базе дольше или сжечь место в кэше. Если маленькие тенанты замедляются, когда один клиент делает пакетный импорт, дизайн требует жёстких лимитов или лучшей изоляции.

Одно правило покрывает большую часть: на каждом рубеже снова подтверждайте идентичность тенанта перед чтением или записью данных.

Простой пример, который ломает первую версию

Небольшое SaaS‑приложение выходит с десятью клиентами, одной базой данных, одной очередью задач и простой таблицей ролей. Каждый пользователь принадлежит аккаунту. Команда быстро выпускает продукт, потому что первая версия кажется маленькой и понятной.

Потом подписывается один крупный клиент. Он приносит 4 000 пользователей, ночные импорты, пакетные экспорты и постоянные повторные вебхуки. Все фоновые задания попадают в одну общую очередь.

Проблема проявляется через несколько дней. Экспорт отчёта для незначительного клиента теперь ждёт за тысячами синк‑задач от крупнейшего аккаунта. Письма для сброса пароля приходят с задержкой. Импорты, которые раньше шли две минуты, теперь идут двадцать. Никто не менял продукт для мелких клиентов, но они всё равно чувствуют замедление.

Потом ломается модель авторизации. Приложение стартовало с ролями на уровне аккаунта: admin, manager и viewer. Это работало, когда у каждого аккаунта было одно рабочее пространство. Новый клиент хочет отдельные рабочие пространства для финансов, продаж и поддержки.

Теперь трещины очевидны. Финансовый админ может открыть настройки, предназначенные для поддержки, потому что несколько эндпоинтов проверяют account_id и роль, но не проверяют членство в рабочем пространстве. UI выглядит нормально в обычных тестах, но граница неверна.

В этот момент команде предстоит рискованная миграция. Нужно разделить очереди, чтобы один тенант не мог затопить всех остальных. Нужны лимиты, воркеры, понимающие тенанты, и лучшее мониторинг. Также нужно переносить права из уровня аккаунта в уровень рабочего пространства, обновлять старые записи и менять каждый хендлер, который полагался на то, что аккаунт равен границе.

Вот как простая первая версия превращается в переработку. Задания, модели данных, правила авторизации и живые данные клиентов должны измениться одновременно.

Ошибки, которые заставляют делать переработку

Некоторые ошибки молчат месяцы, а потом превращают обычную фичу в миграцию.

Добавление tenant ID после запуска — частая ошибка. Команды начинают с общей схемы и говорят себе, что добавят изоляцию позже. Это кажется управляемым, пока биллинг, отчётность, инструменты поддержки и экспорты не начнут требовать контекста тенанта. Тогда вы не просто добавляете колонку. Вы меняете запросы, индексы, фоновые задания, логи и каждую API‑проверку, работающую с клиентскими данными.

Общие кэши приносят ту же проблему. Если ключи кэша не включают префикс тенанта, один клиент может читать чужие разогретые данные или один занятый клиент может сбросить полезные записи кэша для всех. База данных выглядит правильно, а кэш — нет, и такие баги тяжело отлаживать.

Админ‑инструменты ломают систему, когда команды считают их вне обычных правил авторизации. Быстрый внутренний дашборд с широким доступом кажется безобидным на старте. Позже это становится запасным ходом вокруг границ авторизации. Сотрудники поддержки начинают видеть данные по всем тенантам или скрипты обновляют записи без проверки владельца.

Хранилище файлов — ещё одна ловушка. Если вы храните загрузки вместе и полагаетесь на слабые правила именования вроде оригинальных имён файлов или предсказуемых путей, коллизии и путаница станут вероятны. Один клиент загружает «invoice.pdf», другой делает то же самое. Теперь нужна схема именования, правила доступа с учётом тенанта и часто проект по очистке старых файлов, сохранённых неправильно.

Эти признаки обычно означают, что нужны глубокие изменения, а не быстрая правка:

• запросы работают без контекста тенанта
• ключи кэша не включают tenant ID
• админ‑действия пропускают те же проверки, что и пользовательские
• пути к файлам не разделяют данные по тенантам

Строже на старте — обычно хорошая ставка.

Быстрые проверки перед релизом

Дизайн может выглядеть чисто в стейджинге и всё равно запереть вас в болезненной переработке через несколько месяцев. Эти проверки ловят проблемы, которые обычно остаются скрытыми до прихода реальных клиентов.

Прогоните один запрос от начала до конца и задайте простой вопрос: может ли он хоть раз читать или писать данные для двух тенантов одновременно? Иногда утечка очевидна, например отсутствующий фильтр по тенанту. Чаще она прячется в кэше, индексах поиска, фоновых заданиях или инструментах поддержки.

До релиза протестируйте четыре кейса:

• обычный пользовательский запрос касается только строк, файлов, записей кэша и событий этого тенанта
• один занятый тенант не может заполнить очередь воркеров и заставить всех остальных ждать
• сотрудник поддержки может войти в другой тенант только через явное переключение с логированием и понятным состоянием UI
• вы можете перенести одного тенанта в отдельную базу, очередь или кластер без изменений во всём приложении

Тест очередей важнее, чем многие команды предполагают. Один клиент импортирует 500 000 записей, воркеры зависают, и все остальные клиенты видят задержки. Если задачи, лимиты или воркеры общие без ограждений, изоляции на практике нет.

Доступ поддержки требует того же внимания. Если сотрудник может прыгнуть между тенантами по скрытому флагу или трюку в браузере, ошибки гарантированы. Сделайте переключение явным, временным и логируемым. Посредственный аудит‑трек сэкономит реальные деньги позже.

Последняя проверка — про запасные пути. Выберите один тенант и представьте, что он быстро растёт, требует сильной изоляции или просит выделенный сетап. Если перенос означает переписывание ID, правил авторизации, маршрутизации заданий и логики деплоя, дизайн слишком плотный.

Что делать дальше

Начните с границы, которая может навредить быстрее всего. Для большинства команд это не проблема масштабирования в целом. Это утечка между тенантами, общая очередь, которая позволяет большому клиенту замедлять всех остальных, или правило авторизации, которое доверяет неправильному tenant ID.

Выберите самый рискованный рубеж и исправьте его первым. Если данные тенантов могут смешиваться — закройте это раньше, чем будете настраивать производительность. Если проверки авторизации живут только в UI — перенесите их в API и правила базы. Если один клиент может съесть большую часть воркеров — введите лимиты и отдельную ёмкость.

Короткий чек‑лист помогает:

• делайте идентичность тенанта явной в запросах, заданиях и логах
• применяйте авторизацию по тенанту на всех серверных путях
• установите ресурсные лимиты, чтобы один аккаунт не вытеснил остальных
• протестируйте попытку одного тенанта читать, писать или ставить задачи другого

Не ждите следующего большого клиента, чтобы проблему проявить. Напишите путь миграции сейчас, пока система ещё мала и её легче изменить. Этот путь может быть простым: как вы разделите общие таблицы, как будут сопоставляться ID, как перенесёте фоновые задания и как откатиться при ошибке.

Здесь короткий внешний архитектурный обзор может окупиться. Oleg Sotnikov at oleg.is консультирует стартапы и небольшие команды по архитектуре продукта, инфраструктуре и работе Fractional CTO, и такое ревью часто хватает, чтобы заметить дорогостоящие проблемы с изоляцией и авторизацией раньше, чем они разойдутся.

Если у вашей команды уже есть сомнения по поводу изоляции тенантов, noisy neighbors или границ авторизации — проведите ревью дизайна перед крупным релизом.