Агрегатор рекламных событий - это потоковая система, где объём огромен, события приходят не по порядку, а ошибка в учёте напрямую превращается в финансовый и аналитический риск.
Глава помогает разобрать приём событий, удаление дублей, оконную агрегацию, обработку опоздавших событий, исторический пересчёт и выдачу почти актуальных метрик.
В интервью и инженерных обсуждениях этот кейс полезен тем, что быстро выводит разговор на компромисс между пропускной способностью, корректностью и доверием к биллингу.
Дедупликация
Если один клик учитывается дважды, ошибка попадает и в дашборд, и в счёт клиенту, поэтому удаление дублей должно быть встроено в основной путь обработки.
Оконная агрегация
Минутные и часовые окна нужны не только ради скорости, но и ради понятной модели задержки, полноты окна и последующего пересчёта.
Исторический пересчёт
Поздние события, исправления схемы и инциденты неизбежны, поэтому безопасный пересчёт истории нужно проектировать заранее, а не добавлять задним числом.
Свежесть метрик
Пользователю важны не просто цифры, а понимание, насколько они актуальны и где проходит граница между оперативной витриной и биллинговой правдой.
Агрегатор рекламных событий - это кейс про , где нужно одновременно удерживать , корректность биллинга и устойчивый под всплесками рекламного трафика. На интервью этот кейс быстро выводит разговор на границу между быстрым дашбордом и цифрами, которым можно доверять в финансовой отчётности.
Источник
Acing the System Design Interview
Глава 11: проектирование агрегатора рекламных событий с акцентом на удаление дублей, оконную агрегацию и безопасный пересчёт истории.
Где встречается этот паттерн
- Google Ads / Meta Ads: почти актуальные дашборды и отдельный контур финансовой сверки.
- DSP/RTB-платформы: приём кликов, показов и аукционных событий под резкими всплесками нагрузки.
- Партнёрские сети: удаление дублей конверсий и проверки на .
- Внутренние платформы роста: общий событийный контур для продуктовой и маркетинговой аналитики.
Функциональные требования
На функциональном уровне системе нужны надёжный учёт кликов, показов и конверсий без двойного счёта. Поэтому с самого начала важны , входного контура и понятные правила того, как события превращаются в пользовательские и финансовые метрики.
API и контракты
POST /events- приём click/impression/conversion событийGET /metrics- агрегаты по окнам, кампаниям и фильтрамPOST /reconcile- запуск пересчёта и сверки исторических данныхGET /quality- отставание, доля дублей, полнота окна и бюджет ошибок
Платформенные возможности
- Надёжный учёт событий без двойного списания в биллинге
- Минутные, часовые и дневные агрегаты для разных сценариев чтения
- Разделение оперативной витрины и пакетного контура сверки
- Безопасный пересчёт истории из неизменяемого сырого слоя
Нефункциональные требования
От этой системы ждут высокой на входе, понятной границы допустимой задержки и почти нулевой терпимости к ошибкам в биллинге. Поэтому важны не только пиковые числа, но и явный договор о том, какая свежесть нужна дашборду, какое расхождение допустимо и как быстро команда умеет пересчитывать историю после сбоя.
| Требование | Целевое значение | Обоснование |
|---|---|---|
| Пиковая пропускная способность приёма | До 1 млн событий/с | Всплески во время крупных рекламных кампаний |
| Свежесть данных (p95) | < 30 сек | Оперативный дашборд для продуктовых и рекламных операционных команд |
| Отклонение биллинга | < 0.1% | Финансовая корректность и аудит |
| Доступность | 99.95% | Критичный аналитический контур рекламного бизнеса |
| RTO для исторического пересчёта | < 30 мин | Быстрое восстановление после сбоя или коррекции данных |
Архитектура высокого уровня
Теория
Streaming Data
Окна, водяные метки, опоздавшие события, пересчёт истории и баланс между оперативным и пакетным контурами.
Архитектура высокого уровня
приём потока + оконная агрегация + сверка итоговСхема показывает путь приёма, оперативную агрегацию и отдельный контур сверки, который нужен для финансовой корректности.
Архитектура разделяет контур приёма, оперативную агрегацию и отдельный путь контроля корректности. Благодаря этому дашборд получает предсказуемую задержку, а финансово значимые итоги можно проверять и пересчитывать отдельно от пользовательского чтения.
Путь записи и путь чтения
На пути записи система принимает событие, удаляет дубли и обновляет витрину. На пути чтения она старается отвечать из предагрегированных таблиц и кэша, не отправляя пользовательский запрос в сырой поток без необходимости.
Путь записи и путь чтения
Как события превращаются в агрегаты и как дашборд читает метрики под нагрузкой.
Путь записи: система принимает событие, удаляет дубли, обновляет оконные агрегаты и пишет их в витрину для почти актуальной аналитики.
Источники событий
Этап 1SDK, трекеры и пиксели
Клики, показы и конверсии отправляются во входную точку приёма событий.
API приёма
Этап 2проверка и обогащение
Здесь проходит проверка схемы, обогащение и генерация ключа идемпотентности.
Поток и удаление дублей
Этап 3Kafka/PubSub + состояние
Поток обрабатывается с удалением дублей и контролем порядка событий.
Оконный агрегатор
Этап 4минута / час / день
Оконные агрегаты вычисляются и записываются в быструю аналитическую витрину.
Витрина агрегатов
Этап 5ClickHouse/Pinot
Здесь хранятся агрегаты для быстрых аналитических запросов и дашбордов.
Контрольные точки пути записи
- •Идемпотентность на входе защищает от двойного учёта в биллинге.
- •Оконная агрегация считает минутные, часовые и дневные витрины и учитывает опоздавшие события.
- •Неизменяемый сырой слой остаётся источником истины для пересчёта и сверки.
Корректность данных и надёжность
Глубже
Event-Driven Architecture
Событийные контракты, безопасная обработка повторов и управляемая эволюция аналитического пайплайна.
Быстрый дашборд сам по себе ещё не делает систему корректной. Нужны , , обработка , безопасный и отдельное между оперативной витриной и биллинговым контуром.
Двухконтурная модель истины
Для устойчивой аналитики обычно держат два независимых контура: один для быстрого ответа пользователю, второй для регулярной сверки и исправления исторических расхождений.
online_metrics = stream_aggregate(raw_events) billing_metrics = batch_reconcile(raw_events)
- Оперативный контур даёт минимальную задержку для дашбордов
- Пакетный контур максимизирует точность для финансовых отчётов
- Сверка явно фиксирует расхождения и корректирующие записи
Контур качества данных
Без и понятной команда не сможет объяснить, откуда взялась каждая цифра после пересчёта.
- Ключ события: event_id и хранилище дедупликации защищают от двойного учёта.
- Окно ожидания: система явно задаёт, как долго принимает опоздавшие события.
- Версии схемы: изменение формата событий проходит через строгий контракт и обратную совместимость.
- Сырой слой: неизменяемое хранилище позволяет безопасно пересчитывать историю.
Риски и типовые ошибки
На практике такие системы чаще всего ломает не полное падение, а накопительный между сырым потоком, витриной и биллингом. Отдельно нужно следить за тем, не превращаются ли отдельные кампании или ключи в .
- Двойной учёт: слабая дедупликация ломает биллинг и доверие к метрикам.
- Неверные водяные метки: окно закрывается слишком рано или слишком поздно, и агрегаты искажаются.
- Перекос по ключам: один ad_id или campaign_id может перегрузить отдельную партицию сильнее, чем весь остальной поток.
- Непрозрачное происхождение цифр: без понятной трассировки сложно объяснить расхождение на аудите.
- Немая деградация качества: опоздавшие события, проблемы со схемой и пропуски данных долго остаются незаметными без явных защитных ограничений.
Что важно проговорить на интервью
- Как именно система удаляет дубли и почему выбран такой ключ события.
- Где проходит граница между почти актуальной аналитикой и финансово значимой отчётностью.
- Как обрабатываются опоздавшие события, массовый пересчёт истории и возврат к согласованному состоянию после сбоя.
- Какие целевые уровни сервиса и операционные метрики мониторятся: отставание, свежесть данных, доля дублей, полнота окна и расхождение с биллингом.
Связанные главы
- Event-Driven Architecture - Событийные контракты, оркестрация потоков и интеграционные паттерны для аналитических пайплайнов.
- Streaming Data - Фундамент по окнам, водяным меткам, опоздавшим событиям и безопасному пересчёту истории.
- Kafka - Практический разбор журнала с разбиением на партиции и групп потребителей для систем с высоким входным потоком.
- ClickHouse обзор - OLAP-слой для витрин агрегатов, ad-hoc аналитики и контроля стоимости хранения.
- Платформа A/B-тестирования - Смежный кейс, где качество событий напрямую влияет на корректность статистики и интерпретацию экспериментов.
- Payment System - Полезное сравнение подходов к идемпотентности, корректности состояния и регулярной сверке итогов.