Высоконагруженная цифровая платформа «ТНС энерго» с интеграцией региональных биллингов

Главное о кейсе

Для ГК «ТНС энерго» мы создали высоконагруженную цифровую платформу, объединяющую сайты дочерних обществ, личные кабинеты физических и бизнес-клиентов и мобильный сервис с региональными биллинговыми системами.

10 биллингов • 10 регионов • 30+ цифровых сервисов • Мобильные приложения под iOS и Android • ×10 нагрузка в пиковые дни • 2 массовых сервиса без авторизации • эквайринг + цифровой рубль

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

Каждое дочернее общество работает со своим биллингом — мастер-системой по лицевым счетам, показаниям и платежам. Интеграции построены через REST API, а для самых массовых операций реализованы сервисы без обязательной авторизации: пользователь может найти лицевой счет, передать показания и перейти к оплате непосредственно с регионального сайта.

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

Как проект изменил жизнь пользователей

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

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

При передаче показаний система учитывает тип прибора учета и тарифность, показывает предыдущие значения, проверяет некорректный ввод и передает результат непосредственно в Billing через API.

Платежный сценарий также связан с реальными данными лицевого счета: пользователь видит сумму к оплате и задолженность и переходит в платежный контур. В мобильном канале оплата инициируется через API «ТНС энерго» в интернет-эквайринг.

В результате типовая бытовая задача — «передать показания и оплатить свет» — превращена в короткую онлайн-операцию, доступную круглосуточно без визита в офис и без обращения к сотруднику компании.

Бизнес-задача и ее решение

Перед ГК «ТНС энерго» стояла задача модернизировать клиентские цифровые сервисы сразу для нескольких региональных энергосбытовых компаний, сохранив их связь с существующими учетными системами и обеспечив устойчивость при массовых операциях.

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

Мы построили общий подход к интеграциям через REST API и отделили пользовательские цифровые сервисы от региональных учетных систем. Это позволило развивать единый продуктовый слой для всей Группы, сохраняя специфику каждого ДО и его биллинга.

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

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

Крафт (мастерство), реализация, технические детали

Главная инженерная особенность проекта — необходимость одновременно работать с массовой аудиторией, множеством цифровых каналов и 10 региональными биллинговыми системами.

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

Интеграционный контур связывает:
сайты ДО → личные кабинеты → мобильное приложение → REST API → региональные биллинги → платежные сервисы.

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

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

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

Производительность проектировалась не под среднюю нагрузку, а под наиболее тяжелый период — 20–25 числа месяца, когда объем обращений к сервисам возрастает примерно в 10 раз.

В части безопасности применены HTTPS, разграничение прав, WAF, защита от SQL-инъекций, XSS и CSRF, журналирование, двухфакторная аутентификация административных пользователей и дополнительная DDoS-защита.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

Главный инсайт проекта появился при анализе нагрузки: в энергосбыте нельзя проектировать систему по показателям «среднего дня».

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

Поэтому одна из ключевых гипотез звучала так: если оптимизировать только сайты, но оставить интеграции с биллингами синхронным «узким горлышком», пользователь все равно получит медленный или недоступный сервис.

Вместе с командой заказчика мы рассматривали проект не как редизайн группы сайтов, а как перестройку всей цепочки:

пользователь → интерфейс → API → биллинг → банк → подтверждение операции.

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

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

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

Скриншоты