Partitioning по campaign_id и hot-key риски
Как сделать так, чтобы события одной кампании попадали к нужному worker и корректно агрегировались?
Ответить самому
Сначала сформулируйте ответ как на собеседовании, затем откройте разбор и оцените себя.
Короткий ответ
Kafka key по campaign/account упрощает локальную агрегацию, но нужно отдельно продумать hot campaigns, skew и число partitions.
Полный разбор
Если key = campaign_id, все события кампании попадают в одну ordered stream partition, и worker может считать локальные counters без глобального shuffle. Это простой и надежный дизайн для per-campaign dashboard.
Риск - hot campaigns: одна крупная кампания может перегрузить partition. Тогда используют более широкий key, например campaign_id + shard, с последующим merge, или отдельную обработку hot keys. Число partitions выбирают с запасом под throughput и будущий scale-out, потому что уменьшать/менять partitioning после запуска дорого.