Развитие рекламной платформы для онлайн-сервиса доставки продуктов

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

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

О клиенте

Российский онлайн-сервис доставки продуктов и товаров с полок магазинов, который вышел на рынок в 2019.  В 2023 году – занял первое место с самой широкой географией в 83 региона и 14 млн заказов.

Задача

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

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

Процесс

Сервис рекламной платформы был создан уже после перехода на микросервисы на Golang, поэтому требовалось встроить его в инфраструктуру и перенести на общий шаблон. Это позволило передать сложные инфраструктурные задачи DevOps-команде, и выделить время под бизнес-процессы.
При переносе провели рефакторинг: новым специалистам на проекте стало легче погружаться в процессы. 

Этапы работы

Разработчики Holyweb подключились в 2021 году, в момент активного развития и продукта клиента, и рекламной платформы в частности. Срок работы одного из разработчиков на проекте составил 1 год и 3 месяца. За это время команда добилась значительных изменений, повлиявших на бизнес-показатели сервиса доставки.

Есть мнение, что внешние специалисты не заинтересованы в развитии проекта. Наш опыт работы и данные опровергают это:

• На проекте есть разработчики, которые помогают закрывать задачи с 2021 года,
• 75% разработчиков работают два года,
• Специалисты Holyweb занимают ведущие роли в командах, участвуют в онбординге новых специалистов.

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

Скорость работы сервиса

База данных хранит все рекламные кампании. В момент загрузки страницы необходимо пройтись по всем рекламным креативам, достать нужные, провести аукционы – и дать ответ в рамках 200 мс. Это верхняя граница скорости ответа со стороны бэкенда, что влияло на пользовательский опыт: страница могла не прогружаться или делать это с сильной задержкой. А это в свою очередь могло приводить к снижению конверсии в заказ. 

Поэтому специалисты Holyweb вместе с продуктовой командой пришли к другому архитектурному решению. 

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

Такое решение помогло снизить скорость ответа до 20-50 мс на стороне бэкенда

Оптимизация справочников

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

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

Чтобы автоматизировать этот процесс, придумали использовать систему очередей на Kafka. Все микросервисы, использующие словари, подписываются на изменения. Фоновый процесс Worker обращается в Kafka и получает сообщения об обновлении списков, делает копию в общую базу данных. Остальные микросервисы синхронно узнают о новой записи в течение 10 минут. 

Ещё один плюс решения – возможность отследить, откуда поступила запись, исправить её и автоматически дать знать об этом остальным подписчикам справочников. 

Рефакторинг сервиса рекомендаций

Сервис рекомендаций выдаёт пользователям подборки товаров. Изначально был написан на Ruby-монолите, но со временем потребовался перенос на микросервисы Go. 

Для пользователей такой переход остался незаметным и никак не сказался на использовании приложения. 

Трафик переключали постепенно с помощью маршрутизации API Gateway. Сначала старый сервис на Ruby, как и прежде, получал запросы и отвечал на них. Новый, на Golang, просто принимал запросы, чтобы команда могла отследить и настроить работу нового микросервиса. Долю трафика постепенно увеличивали, пока не пришли к полному переключению на новый сервис рекомендаций.

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

Поэтому мы уделили внимание описанию терминов и процессов, сделав их понятными для всех участников: продактов, разработчиков, тестировщиков»‎‎ — Евгений, бэкенд-разработчик

Решение

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

На 150% больше показов рекламы

– благодаря новым рекламным местам и форматам.

В 4 раза меньше ресурсов требуется новому сервису для работы. 

Появился новый роутер, благодаря которому время ответа сократилось: с 200 мс (на верхней границе) до 20-50 мс на стороне бэкенда. 

х10 к устойчивости

– Старый сервис выдерживал 1500 запросов/сек, новый уже 15000 запросов/сек.

В 2023 году сервис доставки отметил рост оборотов рекламной платформы в 3 раза

‍

‍

‍