Sharding трекера нужен раньше, чем начинает падать база и лагать postback

Sharding трекера нужен раньше, чем начинает падать база и лагать postback

Когда один инстанс трекера тащит и клики, и конверсии, и отчёты, узкое место почти всегда не в CPU, а в записи и индексации. Симптомы типовые: растёт latency на postback, отчёты строятся дольше, а очереди на импорт начинают копить хвост.

Первый шаг — разделить нагрузку по ролям:
— отдельная БД под события и отдельная под отчёты;
— write path и read path разнести хотя бы на уровне реплик;
— тяжёлые джобы, ретеншн и агрегации вынести с основного узла.

Если объём растёт дальше, шардируй по времени или GEO, но не мешай оба принципа сразу без схемы маршрутизации. Иначе получишь фантомные расхождения в attribution и сложный rebuild отчётов. Критично заранее определить, где живёт источник истины: raw events, aggregated stats или оба слоя.

Для миграции держи простой чек-лист: заморозка схемы, backfill, сверка хэшей/счётчиков, переключение write path, потом read path. Любой ручной UNION поверх шардов — это временная заплатка, а не архитектура.

Правило простое: если отчёт стал бизнес-критичным, его нельзя строить там же, где принимается трафик.