Ad Click Event Aggregator - это core-компонент рекламной аналитики, где важно одновременно держать freshness, корректность биллинга и масштабируемость. На интервью этот кейс проверяет умение проектировать streaming-пайплайн с понятными контролями качества данных и прозрачным reconciliation.
Источник
Acing the System Design Interview
Глава 11: Design Ad Click Event Aggregator с фокусом на dedupe, windowing и replay.
Где встречается этот паттерн
- Google Ads / Meta Ads: realtime дашборды + финансовая сверка метрик.
- DSP/RTB платформы: high-throughput ingest кликов и аукционных событий.
- Affiliate сети: дедупликация conversion-событий и anti-fraud проверки.
- In-house growth analytics: единый event pipeline для product + marketing команд.
Функциональные требования
Core API / Data Contracts
POST /events- ingest click/impression/conversionGET /metrics- агрегаты по окнам и фильтрамPOST /reconcile- запуск backfill/recomputeGET /quality- lag, duplicate rate, completeness
Product/Platform функции
- Deduplication и idempotent ingest для billing корректности
- Window aggregation: minute/hour/day + поддержка late events
- Dual-path: realtime dashboard и batch reconciliation
- Replay/backfill по диапазонам времени из immutable raw слоя
Нефункциональные требования
| Требование | Целевое значение | Обоснование |
|---|---|---|
| Ingest throughput | Пиково до 1M evt/s | Burst-нагрузка во время крупных кампаний |
| Data freshness (p95) | < 30 сек | Оперативный продуктовый дашборд |
| Billing accuracy drift | < 0.1% | Финансовая корректность и аудит |
| Availability | 99.95% | Критичный аналитический контур для ad бизнеса |
| Replay RTO | < 30 мин | Быстрый recovery после сбоя или data correction |
High-Level Architecture
Теория
Streaming Data
Windowing, watermarks, late events, reprocessing и баланс realtime/batch контуров.
High-Level Architecture
stream ingest + window aggregation + reconciliationСхема показывает ingest-поток, агрегацию окон и контур reconciliation/backfill для финансовой корректности.
Архитектура разделяет ingest, realtime serving и reliability контур с batch backfill/reconciliation. Это даёт предсказуемый SLA для дашбордов и контролируемую финансовую корректность.
Write/Read Paths
Write/Read Paths
Как события записываются в агрегаты и как дашборд читает метрики под нагрузкой.
Write path: ingest принимает события, проводит dedupe/windowing и обновляет serving-агрегаты для near-realtime аналитики.
Event Sources
SDK / trackers / pixels
Клики, показы и конверсии отправляются в ingest endpoint.
Collector API
validate + enrich
Валидация схемы, обогащение и генерация idempotency key.
Stream + Dedupe
Kafka/PubSub + state
Поток обрабатывается с дедупликацией и контролем порядка/late events.
Window Aggregator
minute / hour / day
Оконные агрегаты вычисляются и пишутся в serving-слой.
Serving Store
ClickHouse/Pinot
Хранение агрегатов для быстрых аналитических запросов.
Event Sources
SDK / trackers / pixels
Клики, показы и конверсии отправляются в ingest endpoint.
Collector API
validate + enrich
Валидация схемы, обогащение и генерация idempotency key.
Stream + Dedupe
Kafka/PubSub + state
Поток обрабатывается с дедупликацией и контролем порядка/late events.
Window Aggregator
minute / hour / day
Оконные агрегаты вычисляются и пишутся в serving-слой.
Serving Store
ClickHouse/Pinot
Хранение агрегатов для быстрых аналитических запросов.
Write path checkpoints
- •Идемпотентность на ingress защищает от double counting в биллинге.
- •Window aggregation считает minute/hour/day витрины и учитывает late events.
- •Raw immutable слой остаётся источником истины для replay и reconciliation.
Корректность данных и отказоустойчивость
Глубже
Event-Driven Architecture
Событийные контракты, replay-safe обработка и контролируемая эволюция pipeline.
Dual-path truth model
Для устойчивой аналитики обычно используются два независимых контура:
online_metrics = stream_aggregation(raw_events) billing_metrics = batch_reconcile(raw_events)
- Online path - минимальная задержка для дашбордов
- Batch path - максимальная корректность для финансовых отчётов
- Reconcile - явная фиксация расхождений и корректирующие записи
Контрольные контуры
- Idempotency: event_id и dedupe store защищают от double count.
- Watermarks: late events обрабатываются в заданном grace window.
- Schema governance: строгий контракт и версионирование событий.
- Replay/backfill: raw immutable layer позволяет безопасный пересчёт истории.
Риски и типовые ошибки
- Double counting: отсутствие строгой дедупликации ломает биллинг и доверие к метрикам.
- Watermark misconfig: некорректная обработка late events искажаeт оконные агрегаты.
- Unbounded lag: при burst-нагрузке дашборд теряет актуальность без backpressure.
- Schema drift: неуправляемая эволюция событий приводит к silent data corruption.
- No lineage: невозможность объяснить происхождение метрики при финансовом аудите.
Что важно проговорить на интервью
- Как именно обеспечивается дедупликация и почему выбран такой idempotency key.
- Где проходит граница между realtime-аналитикой и финансово-значимой отчётностью.
- Как система обрабатывает late events, replay и массовые пересчёты истории.
- Какие SLO мониторятся: ingest lag, freshness, duplicate rate, reconcile drift.