SaaS-продукт с нуля: архитектура, мультиарендность и биллинг

SaaS отличается от обычного веб-приложения не интерфейсом, а тем, что одна кодовая база и одна инфраструктура одновременно обслуживают множество независимых клиентов. Именно из этого вытекают все ключевые инженерные решения: как изолировать данные арендаторов, как считать деньги по подпискам, как тарифицировать использование и как расти, не переписывая систему каждые полгода. Ниже — практический разбор без маркетинговой воды.

Мультиарендность: три модели изоляции данных

Мультиарендность (multi-tenancy) — это способ, которым вы храните и разделяете данные разных клиентов в общей системе. Выбор модели определяет стоимость инфраструктуры, скорость разработки и уровень изоляции. На практике используют три подхода.

• Общая схема, общий столбец tenant_id. Все арендаторы живут в одних таблицах, строки помечены идентификатором клиента. Дёшево, просто масштабировать, но требует дисциплины: каждый запрос обязан фильтровать по tenant_id.
• Схема на арендатора. Одна база, но у каждого клиента своя схема. Лучше изоляция, проще резервное копирование отдельного клиента, но миграции усложняются при сотнях схем.
• База на арендатора. Максимальная изоляция, подходит для крупных корпоративных и регулируемых клиентов (банки, медицина). Дорого в эксплуатации и тяжело автоматизировать.

Биллинг и подписки: ядро, которое нельзя недооценить

Биллинг кажется простым ровно до первого продакшена. На деле подписочная логика — это конечный автомат состояний: trial, active, past_due, grace period, suspended, canceled, refunded. Каждое состояние влияет на доступ к функциям и на выставление счетов. Если зашить это в разрозненные if-ы по коду, поддержка превратится в ад.

Ключевые компоненты биллинга:

• Каталог тарифов и фич — что входит в план, какие лимиты, какие функции включены.
• Подписки — связка «арендатор + план + период + статус» с историей изменений.
• Инварианты счетов — генерация инвойсов, пропорциональный пересчёт (proration) при апгрейде/даунгрейде в середине периода.
• Платёжный слой — интеграция с провайдерами и обработка вебхуков об оплате.
• Реконсиляция — сверка статуса подписки с фактическими платежами. Один счётчик никогда не считать истиной.

Отдельно про реалии Узбекистана: международные Stripe/Paddle здесь напрямую недоступны для приёма локальных платежей. Рабочая схема — интеграция с локальными провайдерами: Payme, Click, Uzum. У каждого своя модель вебхуков, своя проверка подписи и свои требования к возвратам. Закладывайте абстракцию платёжного шлюза с самого начала, чтобы добавление второго и третьего провайдера не ломало ядро подписок.

Тарифы: как упаковать ценность

Модель тарификации — это продуктовое решение с прямым влиянием на выручку. Основные схемы:

Несколько правил, проверенных практикой:

• Привязывайте цену к метрике, которая растёт вместе с ценностью для клиента (число сотрудников, обработанных заказов, устройств), а не к технической нагрузке.
• Делайте лимиты мягкими: предупреждение и грейс лучше, чем резкое отключение, которое рождает отток.
• Храните тарифы как данные, а не как код. Новый план или акция не должны требовать релиза.

Для рынка Узбекистана цены чаще указывают в сумах, а корпоративный сегмент привык к договору и ЭСФ (электронным счёт-фактурам). Если продаёте юрлицам, биллинг должен уметь выгружать данные для бухгалтерии, а не только списывать с карты.

Масштабирование: сначала измеряй, потом дроби

Преждевременное усложнение — частая болезнь. Микросервисы, Kubernetes и шардинг на этапе 50 клиентов чаще вредят, чем помогают. Правильный путь — расти по узким местам, опираясь на метрики.

• Вертикально и через кэш на старте: индексы в БД, кэширование горячих запросов, пул соединений (PgBouncer для PostgreSQL).
• Горизонтально для stateless-слоя: несколько инстансов приложения за балансировщиком, фоновые задачи в очередях.
• Шардинг по tenant_id — только когда одна БД реально перестаёт справляться. Хорошая новость: при правильной мультиарендности tenant_id уже есть естественный ключ шардирования.
• Региональная близость: для узбекской аудитории латентность до серверов в ЕС/США ощутима. Локальный хостинг или read-реплика ближе к пользователю заметно улучшают отклик кабинета.

Метрики: что измерять, чтобы управлять

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

• MRR / ARR — регулярная месячная и годовая выручка, основа всей экономики подписок.
• Churn — отток клиентов и отток выручки (revenue churn важнее, чем логотипы).
• LTV и CAC — пожизненная ценность клиента против стоимости его привлечения; здоровое отношение LTV/CAC от 3 и выше.
• Activation — доля клиентов, дошедших до ключевого действия (первая реальная ценность), а не просто зарегистрировавшихся.
• Expansion / NRR — доращивание выручки на существующих клиентах за счёт апгрейдов и доп-мест.

Технически метрики лучше строить на событиях (event log), а не на текущем срезе таблиц: так вы сможете восстановить историю и не потеряете факты при изменении схемы.