Как выбрать архитектуру SaaS, если продукт ещё не нашёл рынок

До того как продукт нашёл рынок, вы не знаете главного: какие функции будут нужны, кто будет платить и в каком объёме. Архитектура, рассчитанная на миллион пользователей, в этот момент — ставка на будущее, которого может не быть. Мартин Фаулер в заметке «Monolith First» формулирует это через вопрос: когда вы начинаете новое приложение, насколько вы уверены, что оно будет полезно пользователям? Пока уверенности нет, скорость обратной связи важнее масштабируемости.

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

Арендатор (tenant) — это тот, чьи данные должны быть отделены от других. В B2B это обычно компания-клиент со своими сотрудниками; в B2C — человек, семья или группа. Руководство Microsoft по многоарендным решениям подчёркивает: выбор модели — не только техническое, но и коммерческое решение, потому что он определяет себестоимость клиента, требования к соответствию и то, что вы сможете продавать.

Термины pool, silo и bridge взяты из SaaS Lens AWS Well-Architected; Microsoft описывает те же варианты как полностью многоарендное, вертикально и горизонтально разделённое развёртывание. Для раннего B2B-продукта рабочий выбор по умолчанию — общие ресурсы с идентификатором арендатора и проверкой доступа в двух местах: в коде приложения и в базе. В PostgreSQL второй рубеж дают политики Row Level Security: после их включения доступ к строкам запрещён, пока политика его явно не разрешит. Важная деталь из документации: владелец таблицы обычно обходит эти политики, если не включить FORCE ROW LEVEL SECURITY.

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

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

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

Этот список не требует большой команды. Каждый пункт дёшев в начале и дорог, если добавлять его в продукт с живыми клиентами.

Откладывать не значит игнорировать. Хорошая практика — записать для каждого отложенного решения сигнал, при котором к нему нужно вернуться. Тогда отказ от сложности становится осознанным решением, а не пробелом.

Через год никто не вспомнит, почему выбрали именно эту модель арендаторов или этот провайдер аутентификации, — а именно эти вопросы зададут новый технический руководитель, команда, которая примет продукт, или технический эксперт инвестора. Простой инструмент — запись архитектурного решения (Architecture Decision Record, ADR), формат которой предложил Майкл Найгард.

• Название — короткая фраза: «Общая база с идентификатором арендатора».
• Контекст — какие силы и ограничения действовали: число клиентов, требования, команда, сроки.
• Решение — что решили, в активном залоге.
• Статус — предложено, принято, устарело или заменено другим решением.
• Последствия — все, не только положительные: что стало проще, что сложнее, какой сигнал заставит пересмотреть.

Записи хранятся в репозитории рядом с кодом, нумеруются по порядку, номера не переиспользуются. Если решение пересмотрели, старую запись не удаляют, а помечают как заменённую и ссылаются на новую. Десяток таких записей объясняет архитектуру лучше, чем большой документ, который перестал совпадать с кодом.

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