Привет, меня зовут Илья Иванов, и я занимаюсь разработкой биллинга в Яндекс 360, куда входят Диск, Почта, Телемост, Мессенджер, Календарь и другие сервисы для решения повседневных задач. Ежедневно наши сервисы обслуживают 80 миллионов пользователей и более 130 тысяч организаций, обрабатывая свыше 1 миллиона запросов в секунду.

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

Архитектура биллинга для экосистемы

Давайте разберемся, что же такое экосистема? Например, Яндекс — это экосистема. Это множество разных сервисов, которые взаимодействуют друг с другом для улучшения пользовательского опыта. Основная цель экосистемы — приносить прибыль. Значит, нужен биллинг. Нужен, значит делаем.

А какие вообще есть варианты реализации архитектуры современного биллинга? Для начала давайте рассмотрим решение в лоб: единый Биллинг на примере метафоры «Волшебного Дома».

Добро пожаловать в «Волшебный Дом»

В «Волшебном Дом»е есть несколько сервисов с разными моделями монетизации.

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

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

Всесильный погодник — сервис, который меняет погоду по желанию пользователя. Он тарифицируется посекундно.

Последний сервис — тренер по йоге для котов. Приложения для йоги котов продаются через внешние магазины.

Если мы реализуем единый биллинг, он должен содержать в себе логику оплаты всех этих сценариев. Но что происходит, если добавляется новый сервис? Например, появляется «Планкостоятель» — сервис, который начисляет пользователю бонусы за то, сколько он простоял в планке (а все мы знаем, что первые 30 секунд в планке — не то же самое, что вторые). Он осуществляет посекундную тарификацию с учетом роста стоимости за время, проведенное в планке. Чтобы поддерживать его, нужно:

1. Добавить новую механику в биллинг.

2. Унифицировать существующую механику с учетом новых требований.

В любом из этих случаев возникают сложности:

• Разрастание функциональности. С каждой новой механикой биллинг становится более громоздким, в конце концов будет сложно разобраться, какая логика за что отвечает.

• Коммуникации между сервисами. «Планкостоятель» должен договориться с разработчиками, поддерживающими «Всесильного Погодника», о том, как унифицировать посекундную тарификацию. Это затягивает процесс разработки.

• Конфликты интересов. У команд сервисов часто бывают разные цели, это может создавать конфликты интересов, замедляющие внедрение.

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

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

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

Экосистемы, такие как Яндекс 360, объединяют множество разнородных сервисов с разными моделями монетизации. Например, одни сервисы работают по подписке, другие используют посекундную тарификацию, а третьи продаются через разовые платежи. Чтобы эффективно поддерживать все эти сценарии, нам понадобилась гибкая архитектура биллинга.

Как появился биллинг Яндекс 360

Чтобы понять, как работает биллинг Яндекс 360, начнём с истории.

Много лет назад в Яндексе появился Диск. Это был первый сервис Яндекса, который продавался по подписке через единый биллинг. Позже к Диску присоединилась Почта, которая тоже захотела работать с подписками. На этом этапе перед нами встал выбор: либо усложнять логику единого биллинга, либо поддерживать монетизацию отдельно на стороне сервисов. Мы начали задумываться о более гибком подходе.

Когда появился Яндекс 360, объединяющий множество сервисов (Диск, Почту, Телемост, Календарь и другие), необходимость в унифицированной системе стала очевидной. Все сервисы нужно продавать по единой подписке, и для этого был создан биллинг Яндекс 360.

Биллинг Яндекс 360:

• Содержит информацию о существующих тарифах и акциях.

• Отправляет запросы на списание средств в единый биллинг Яндекса.

• Управляет купленными услугами в продуктовых сервисах.

Теперь вопрос: если у Яндекс 360 есть свой биллинг, а у Яндекса — единый биллинг, то как обстоят дела с остальными сервисами? Ответ прост: у каждого бизнеса в экосистеме, как правило, есть свой pre‑billing, который формирует запросы на списание средств. Каждый pre‑billing создаётся под нужды конкретного бизнеса и работает независимо, чтобы не мешать другим.

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

Pre‑billing берет на себя всю логику, связанную с монетизацией конкретного бизнеса:

• Обработка сложных сценариев тарификации. Например, если нужно учитывать посекундную тарификацию с нарастающим коэффициентом, как в случае с «Планкостоятелем», pre‑billing управляет расчётом и формированием платежного запроса.

• Управление промо‑акциями. Pre‑billing хранит данные о скидках, промокодах и других маркетинговых акциях, позволяя бизнесу быстро внедрять новые предложения.

• Адаптация под требования бизнеса. Если сервису нужно ввести уникальную механику списания средств, это можно сделать в рамках его pre‑billing, не затрагивая другие бизнесы.

За общие задачи отвечает единый биллинг:

• Обработка платежей. Единый биллинг принимает запросы на списание средств, отправленные pre‑billing, и взаимодействует с платежными системами.

• Формирование отчетности. Он готовит документы для налоговых органов и отправляет чеки пользователям.

• Обеспечение соответствия. Общий биллинг контролирует соблюдение юридических и финансовых требований.

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

Преимущества подхода pre‑billing:

1. Изоляция логики бизнеса. Каждая команда получает контроль над своим pre‑billing и может адаптировать его под собственные задачи. Это исключает конфликты с другими бизнесами.

2. Ускорение внедрения новых функций. Любая модификация или добавление механики происходит только в рамках конкретного pre‑billing, что сокращает время разработки и согласований.

3. Масштабируемость. Pre‑billing легко масштабировать в зависимости от нагрузки или роста бизнеса.

4. Устойчивость к сбоям. Если один pre‑billing сталкивается с проблемами, это не влияет на работу других сервисов.

Как устроен Биллинг Яндекс 360

Биллинг Яндекс 360 — это сервис, который отвечает за все домены, связанные с монетизацией. Давайте верхнеуровнево рассмотрим, за какие домены отвечает наша команда.

Тарификатор

Тарификатор — это отдельный модуль, который знает всё про тарифы, промо‑акции и скидки. Он отвечает за то, как мы показываем пользователю наши предложения. Вот, что он делает:

• Хранит информацию о тарифах и их условиях.

• Управляет акциями, промокодами и другими инструментами, которые помогают продавать продукт.

• Умеет показывать пользователю правильный тариф в зависимости от контекста: страны, сегмента, текущего статуса.

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

Платёжные механики

Здесь мы собрали логику, которая отвечает за списание денег:

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

• Платёжные механики знают, когда продлить подписку или как обработать запрос на возврат средств.

• Отправляют сформированный запрос в единый биллинг, который уже непосредственно взаимодействует с платёжной системой.

  

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

Управление услугами

Управление услугами — это то, что делает биллинг Яндекс 360 не просто системой для платежей, а полноценным оркестратором фичей. Он отвечает за:

• Подключение услуг после оплаты.

• Отключение услуг, когда подписка закончилась.

• Включение фичей в продуктовых сервисах, например, добавление места на Яндекс Диске.

Пример: пользователь оплатил подписку, мы передали запрос в Яндекс Диск, там добавили место, а дальше сам Диск уже знает, можно ли пользователю загрузить файл.

Как всё это работает вместе

Когда пользователь покупает тариф:

1. Тарификатор определяет, какой тариф он выбрал, и передаёт информацию платёжным механикам.

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

3. После успешной оплаты управление услугами включает нужные фичи в продуктовых сервисах.

Почему это эффективно? Мы изолировали логику каждой части системы, что позволяет легко добавлять новые фичи, не ломая ничего старого. В результате:

• Тарификатор отвечает за создание тарифов.

• Платёжные механики — за списания.

• Управление услугами — за работу с фичами.

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

Технические детали

Для тех, кто любит закапываться в сложные технические вещи, расскажем про интересные детали в разных частях Биллинга Яндекс 360.

Как работает B2B-тарификация

В B2B‑сегменте компании покупают групповые услуги для своих сотрудников, например, доступ к облачному хранилищу. При этом нужно учитывать:

• Количество сотрудников в организации.

• Изменения в численности команды (увеличение или уменьшение).

• Специфические условия оплаты, такие как тарификация за использованное время.

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

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

Синхронизация услуг и групповые услуги

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

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

1. Групповые фичи.

2. Индивидуальные фичи для участников.

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

Этапы работы схемы:

1. Инициализация услуги.

   • Когда создаётся групповая услуга, она переводится в состояние init (инициализация). Это означает, что услуга зарегистрирована в системе, но ещё не активирована.

   • В рамках услуги формируются дочерние сущности — групповые фичи и фичи участников.

2. Переход в состояние синхронизации.

   • После создания всех дочерних сущностей услуга переходит в состояние syncing (синхронизация).

   • На этом этапе каждая дочерняя сущность (например, место на Диске для сотрудника) начинает процесс включения в соответствующих продуктовых сервисах.

3. Отправка запросов на активацию.

   • Для каждой фичи формируется асинхронная задача (one‑time‑task), которая отправляет запрос в конкретный продуктовый сервис, например, Яндекс.Диск.

   • Продуктовый сервис подтверждает активацию, если процесс прошёл успешно.

4. Подтверждение успешного включения.

   • Когда продуктовый сервис возвращает ответ «ОК», соответствующая фича переводится в состояние actual (актуально). Это означает, что услуга включена и готова к использованию.

5. Обработка ошибок.

   • Если продуктовый сервис возвращает ошибку, задача переходит в состояние snoozing (отложено).

   • Система выполняет повторные попытки активации с заданными промежутками времени, пока сервис не подтвердит успешное включение.

6. Завершение синхронизации.

   • Когда все дочерние сущности переводятся в состояние actual, групповая услуга также становится актуальной.

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

Как мы измеряем качество биллинга

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

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

Для нас важно, чтобы:

1. Все процессы активации работали согласованно.

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

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

Мы собираем множество метрик, чтобы быть уверенными, что система работает как надо:

• Проверяем, что платёжные запросы обрабатываются без ошибок.

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

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

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

Что в итоге 

Биллинг Яндекс 360 — это не просто система для обработки платежей, а гибкий инструмент, который учитывает потребности каждого сервиса в Яндекс 360. Благодаря разделению на pre‑billing и общий биллинг, мы избегаем конфликтов интересов, ускоряем внедрение новых функций и обеспечиваем стабильность даже при высоких нагрузках. Такой подход позволяет пользователю достаточно быстро получать доступ к купленным услугам, а нам — адаптироваться к постоянно изменяющимся бизнес‑требованиям.