Ad Click Aggregator

Задача

Спроектировать ad click aggregator уровня Google Ads / Facebook Ads: принимать миллионы кликов в секунду, агрегировать per-ad-per-minute / hour / day, предотвращать фрод (дедуп, бот-фильтр), выставлять рекламодателю точный счёт. Главная боль — биллинг должен быть exactly-once: пере-зачёт = жалобы регулятору, недо-зачёт = потеря выручки.

Требования

Functional:

• Track click event: (ad_id, user_hash, ts, geo, device, ip, referrer, cost_micros).
• Aggregate counts + spend per (ad_id, minute) → (hour) → (day).
• Dedup duplicate event_id внутри 5-минутного окна.
• Fraud filter: rate limits, datacenter ASN check, headless UA detection.
• Billing ledger: append-only, immutable, ежедневный reconciliation против S3 raw.
• Real-time advertiser dashboards (sub-minute lag).

Non-functional:

• 1M clicks/sec sustained, 5M peak (Super Bowl tier).
• End-to-end latency from click → dashboard < 60s p99.
• Billing accuracy: <0.01% drift между streaming ledger и batch recompute.
• Ingestion availability ≥ 99.99% (потеря клика = потеря денег).
• 30 дней replay capability для bug fixes.

Capacity

Архитектура

Browser/Mobile -> Edge CDN -> L7 LB -> Click Ingest API -> Kafka (clicks topic, 5K partitions)
                                                                |
                                                                v
                                          Flink: Enrich -> Dedup -> Fraud -> Window Agg (1m)
                                            |          |        |             |
                                            +-> S3 raw | RocksDB Redis        +-> Druid (OLAP)
                                            |  (audit) | event_id features    +-> Postgres ledger
                                            |          |                          (billing)
                                            +------ Checkpoint S3 -----------+
                                                                |
                                          Reports API --> Druid + Ledger + S3 (reconcile)

Сценарии

Happy path: клик летит browser → edge → ingest API → Kafka. Flink consume → enrich (добавляет campaign_id, advertiser_id) → dedup (RocksDB lookup по event_id, miss) → fraud filter (Redis feature lookup, signals OK) → 1-min tumbling window aggregator. По истечении окна emit segment в Druid + INSERT в billing ledger. End-to-end < 60s.

Dedup duplicate: beacon retry после network blip отправляет тот же event_id дважды. Второй заход доходит до dedup, который смотрит RocksDB — event_id уже видели 30s назад. Дроп, но в S3 raw всё равно пишем (для аудита). Counter в Druid не инкрементится, ledger не трогается — без двойной оплаты.

Fraud bot: click farm шлёт 10K кликов/сек с одного IP, headless Chromium UA, без impression context. Fraud filter (online ML model + Redis feature store) флагает: rate > 5K/s + datacenter ASN + UA pattern. Дроп. Событие тэгается fraud=true и идёт в S3 для analytics (но не в billable count). Advertiser CTR не раздут, $0 charged.

Hot ad partition skew: виральная реклама SUPER_BOWL_2026 получает 500K rps на одну партицию (100× средней). Kafka партиция #1247 backlog растёт до 3M сообщений, p99 latency до 8s. Mitigation: producer переключается на sub-key salting (ad_id + bucket(0..31)), нагрузка размазывается по 32 sub-партициям. Aggregator scales out 10× реплик. Lag падает обратно до <1m.

Daily reconciliation: в t+24h Spark batch job читает S3 Iceberg raw для прошлого дня, пере-агрегирует независимо от streaming, сравнивает результат с billing ledger. Обнаружен delta $1,247 на advertiser_id=acme (0.003% от их spend). В пределах SLA tolerance (<0.01%) — emit adjustment txn в ledger, ledger sealed для billing run. Над тхreshold — алерт + manual review.

Trade-offs / ADRs

ADR-001: Exact aggregation (Flink) vs Approximate (HyperLogLog / Theta sketch)

Контекст: Нужно считать clicks (точно — это деньги) и unique_users (приблизительно — для CTR/reach метрик в дашборде).

Опции:

Решение: Hybrid. Flink exact aggregation для billable counts (clicks, spend) — это деньги, ошибаться нельзя. Theta sketch в Druid для unique_users / reach — погрешность 1-2% невидна в дашборде, но storage и latency на 2 порядка лучше. Daily reconciliation против S3 батчем как safety net (ADR-001 = lambda-light: stream owns truth, batch verifies).

Последствия: Сложность two paths, но сохранение exact billing + дешёвые approximate метрики. Альтернатива (всё approximate) проигрывает регулятору; всё exact — слишком дорого по storage и query latency.

ADR-002: Dedup window size — 5 минут vs 1 час vs 24 часа

Контекст: Дедупликация по event_id нужна, потому что beacons ретраятся при сетевых ошибках, мобильные SDK буферизуют события offline и могут флашить дубли.

Опции:

Решение: 5-минутное окно для inline dedup в Flink (16 GB state влезает в RocksDB на воркере, checkpoint быстрый). + secondary daily dedup в batch reconcile для случаев offline-buffered mobile (event приходит через 6 часов после клика). Late события (старше 5m) идут в side-output Kafka topic → batch dedup при ежедневной reconciliation.

Последствия: В streaming path возможны редкие дубли от late mobile events (<0.05%), но они ловятся в daily batch и corrected в ledger до billing run. Storage в 12-30× дешевле, чем full 1h/24h state. Альтернатива (24h) даёт 100% inline accuracy, но требует TB+ state на воркер и убивает checkpoint latency.

Failure modes

Real systems

• Google Ads — Mesa system (VLDB 2014): versioned aggregations, multi-DC sync.
• Facebook Ads — Scuba для interactive analytics + custom Hive aggregations.
• TikTok / ByteDance — heavy streaming aggregations через ByteHouse.
• Twitter Ads — Heron + ClickHouse.
• Adjust / AppsFlyer — мобильная attribution, similar shape.

Связанные