C++ инженер (ad-serving bridge)

Что предстоит делать

<h3>Описание роли</h3><p>Один из инженеров на живом пути запросов рекламного моста между supply-side платформой и программной линейной биржей японского вещателя. Путь проходит от входящей возможности показа рекламы через сопоставление сделок и управление темпом показа, фильтрацию креативов и ограничений, выбор и ответ, который получает вещатель. Клиент остановился на C++ для этого пути и считает этот выбор окончательным.</p><p>Их причина выбора C++ — переиспользование, а не сырая скорость. Клиент модуляризирует свой существующий C++ ad server, чтобы компоненты можно было подключать к этому новому приложению, а не вызывать через границу сервисов; их примером была библиотека аудиторий и сегментов, а их заявленная цель — чтобы всё было объединено вместе, а задержки были очень строгими. Таким образом, инженер на этой позиции пишет новый код и использует библиотечный парк, который он не писал, внутри системы сборки, принадлежащей кому-то другому. Эта работа по модуляризации находится на стороне клиента и не несёт данных, что делает её зависимостью, а не данностью.</p><p>Тайминг запросов задаётся вещателем. Слоты с фиксированным временем вещания получают запрос примерно за минуту до эфира; слоты без привязки ко времени получают его за одну-три секунды до эфира. Один слот может порождать три или более последовательных подзапроса, при этом запрос следующего сегмента отправляется, пока предыдущий рекламный ролик ещё идёт, поэтому состояние уровня перерыва должно сохраняться в этой цепочке. Клиент описывает работу как проектирование высоконагруженной системы. Спецификация не раскрывает ни целевой объём запросов, ни таймаут ответа, поэтому рассматривайте требование к пропускной способности как заявленное клиентом и не количественно определённое в документации.</p><p>Полная занятость с первого этапа до передачи в production. Подчиняется нашему solution-архитектору, который владеет внутренней моделью и контрактами интерфейсов, и работает вместе с Go-инженером на стороне расчётов.</p><h3>О проекте</h3><p><strong>Клиент</strong>: устоявшаяся supply-side платформа, работающая в масштабе. Вовлечение — полностью аутсорсовая разработка. Клиент предоставляет продакт-менеджера для требований и объёма, архитектора в режиме ревью и надзора, и специалиста по инфраструктуре для UAT и production сред. Мы владеем поставкой, архитектурой и всем, что до UAT.</p><p><strong>Продукт:</strong> рекламный мост, соединяющий клиента с программной линейной платформой японского вещателя, построенный отдельно от основного RTB-стека клиента. Он работает как слой трансляции и как облегчённая supply-side платформа, проводящая аукцион. Три стороны определяют его границы:</p><ul><li>Биржа вещателя является источником возможностей показа рекламы, доступ к которому осуществляется через спецификацию соединения, которую определяет вещатель, а мы реализуем, не имея возможности её изменить.</li><li>Внешняя система рейтингов просмотра решает, сколько людей увидело каждый рекламный ролик. Мы никогда её не вызываем. Биржа получает количество показов из этих рейтингов и сообщает их дважды: предварительно вскоре после эфира, подтверждённо на следующий рабочий день.</li><li>Поверхность конфигурации клиента предоставляет спрос в виде активированных прямых сделок. Опциональная вторая фаза добавляет сторонние demand-side платформы через oRTB.</li></ul><p><strong>Фазирование:</strong> обязательная первая фаза полностью работает в нативном протоколе вещателя и не требует конвертации протокола. Опциональная вторая фаза добавляет конвертацию oRTB и прямую связь с demand-side платформами. Внутренняя модель выровнена по oRTB с первой фазы, поэтому вторая становится задачей маппинга на границах.</p><p><strong>Текущее положение:</strong> greenfield. Ничего не построено. Спецификация соединения вещателя существует и версионируется, хотя история её ревизий показывает продолжающиеся правки. Документ с требованиями пока не существует.</p><p><strong>Стек:</strong> C++ на пути запросов, выбранный клиентом, с Go на стороне расчётов и сверки. Система разворачивается в собственных дата-центрах клиента и должна быть построена cloud-ready, по словам клиента, чтобы перенос в облако позже не был отдельным проектом.</p><h3>Ключевые обязанности</h3><p><strong>Путь запросов</strong></p><ul><li>Построить обработчик рекламных запросов и состояние уровня перерыва, которое переживает разделённый плейлист, когда запрос следующего сегмента отправляется, пока предыдущий рекламный ролик ещё в эфире.</li><li>Построить сопоставление сделок и движок управления темпом показа против потолка бюджета и показателя аудитории, который не фиксируется до следующего рабочего дня.</li><li>Построить фильтрацию креативов и ограничений: правила временных диапазонов, распределения слотов, позиции и смежности в упорядоченном рекламном перерыве.</li><li>Построить выбор и сборщик ответов в формате вещателя, включая предпочтительную позицию в перерыве. Оценка по первой цене — текущее ожидание клиента, а не фиксированное решение.</li><li>Аукционный движок (первая цена)</li></ul><p><strong>Интеграция с существующей платформой клиента</strong></p><ul><li>Подключать и использовать компоненты из существующего C++ ad server клиента по мере их доступности в результате модуляризации, а не вызывать их через границу сервисов.</li><li>Поддерживать внутреннюю модель запросов и ответов выровненной по oRTB — решение, которое клиент уже принял, чтобы опциональная вторая фаза оставалась задачей маппинга на границах.</li><li>Строить cloud-ready для системы, которая разворачивается в дата-центрах, которыми команда не управляет.</li></ul><p><strong>Корректность в условиях эфирного дедлайна</strong></p><ul><li>Относиться к эфирному окну как к дедлайну, которым оно и является. Поздний ответ означает рекламный слот, который платформа не заполнила.</li><li>Фильтровать консервативно в соответствии с правилами ограничений, которые биржа перепроверяет на своей стороне, исключая любой креатив, который их нарушает. Неверное правило стоит потери доставки.</li><li>Удерживать состояние в цепочке подзапросов в рамках одного слота, где одно решение выполняется, пока предыдущий рекламный ролик играет.</li></ul><h3>Требуемая квалификация</h3><p><strong>Опыт</strong></p><ul><li>6+ лет production C++, включая как минимум один сервис, работавший под бюджетом задержки, установленным кем-то другим.</li><li>Работал внутри большой C++ кодовой базы, написанной другими людьми, включая её систему сборки, и подключался к внутренним библиотекам, а не только писал автономные сервисы.</li><li>Строил или поддерживал компонент на живом пути ad server, биржи или биддера.</li><li>Реализовывал спецификацию протокола, принадлежащую другой организации, где контракт нельзя было изменить.</li></ul><p><strong>Техническая проницательность</strong></p><ul><li>Современный C++ с владением, временем жизни и конкурентностью, обрабатываемыми осознанно, а не по привычке.</li><li>Системы сборки и управление зависимостями для большой нативной кодовой базы, включая подключение к внутренним библиотекам, поставляемым другой командой.</li><li>Проектирование сервисов, чувствительных к задержке: таймауты, распространение дедлайнов, backpressure и то, что сервис делает, когда дедлайн наступает первым.</li><li>Обработка запросов с сохранением состояния в последовательности связанных вызовов, а не stateless запрос и ответ.</li><li>Семантика объектов OpenRTB, достаточная для поддержания внутренней модели в соответствии с ними без поставки слоя конвертации.</li><li>Оценка ограничений по упорядоченной последовательности: правила смежности, позиции и конкурентного разделения.</li><li>Создание для среды, в которую команда разворачивает, но которой не управляет.</li></ul><p><strong>Суждения и мягкие навыки</strong></p><ul><li>Читает спецификацию перед написанием кода по ней и спрашивает, когда она неоднозначна, вместо того чтобы молча выбрать интерпретацию.</li><li>Понимает, что неверное правило фильтрации теряет доставку без возникновения ошибки, поэтому относится к логике ограничений как к проблеме корректности.</li><li>Работает по модели архитектора и письменно возражает, когда она не выдерживает контакта с кодом.</li><li>Комфортно себя чувствует, будучи заблокированным графиком другой организации, и сообщает об этом заранее с указанием ответственного лица и даты.</li></ul><h3>Знание домена — обязательно</h3><p><strong>Эта позиция требует знания adtech-домена</strong> по конкретной причине. Путь запросов решает, какой рекламный ролик выйдет в рекламном перерыве на национальном телевидении, в соответствии с правилами, которые устанавливает вещатель и перепроверяет на последующих этапах. Инженер, сильный в C++ и пустой в домене, напишет корректный код на основе неверного прочтения спецификации, и ничто не будет выглядеть сломанным. Особенности этого вещателя можно изучить за недели. Рассуждения, лежащие в основе, — нет.</p><p>Требуется и переносится между adtech-платформами:</p><ul><li>Механика программных аукционов со стороны продавца: что такое возможность показа, ставка, выигрыш и доставленный показ, и почему выигранная ставка — это не доставленный показ.</li><li>Семантика объектов запроса и ответа OpenRTB и соглашения о расширениях.</li><li>Композиция рекламных подборок и перерывов: ограничения длительности, позиция в перерыве и конкурентное разделение между рекламодателями.</li><li>Управление темпом: равномерное расходование бюджета против инвентаря, доступный объём которого варьируется.</li><li>Правила допустимости креативов и ограничений как задача фильтрации, которая выполняется до аукциона.</li></ul><p>Специфично для этого проекта и ожидается, что будет освоено, а не уже имеется:</p><ul><li>Диалект биржи вещателя и её таксономия ограничений.</li></ul><p>Ожидается глубина в инженерии ad serving, бирж или биддеров. Кандидат, сильный в C++ и пустой в домене, — более медленный и рискованный найм здесь.</p><h3>Желательно</h3><ul><li>CTV ad podding или линейные системы трафика и планирования, где конкурентное разделение обязательно, а не рекомендательно.</li><li>Движки управления темпом или доставки бюджета, работающие с инвентарём переменного объёма.</li><li>Go, так как сторона расчётов написана на нём, и граница между двумя сторонами не устоялась.</li><li>Опыт работы с технической документацией в переводе.</li><li>Создание системы, которая позже была поглощена библиотечным парком более крупной платформы.</li></ul> <div> <a href="https://jobs.dou.ua/companies/xenoss/vacancies/371339/#reply-btn-id">Відгукнутись на вакансію</a> </div>