Sharding трекера: как не уронить атрибуцию, когда поток конверсий упирается в один сервер

Sharding трекера: как не уронить атрибуцию, когда поток конверсий упирается в один сервер

Если трекер начинает тормозить, проблема обычно не в «слабом VPS», а в том, что в одной точке смешаны сбор кликов, запись конверсий, редиректы, отчёты и API. Шардирование — это не просто разнести нагрузку, а заранее разделить контуры: по GEO, по офферам, по источникам или по типам событий.

Базовое правило: клики и конверсии должны писать в максимально короткий путь. Всё тяжёлое — постобработка, агрегация, антифрод-правила, экспорт в BI — выноси в отдельный слой. Если отчёт строится из той же базы, куда летят боевые postback’и, у тебя рано или поздно начнутся задержки и «потерянные» события.

Практика такая:
— один shard на write-heavy трафик;
— отдельные базы под архив и аналитику;
— маршрутизация по стабильному ключу: GEO, affiliate_id, campaign_id;
— TTL и ретеншн считать до внедрения, а не после.
Иначе шардирование превращается в хаос, где миграция ломает дедупликацию и разбивает цепочки атрибуции.

Следи за тем, чтобы postback URL, токены и mapping полей были одинаковыми между shard’ами. Если логика дедупа живёт только в приложении, при фейловере ты получишь дубли или пустые конверсии. Лучше держать единый слой нормализации и проверять его на тестовом потоке перед переносом боевого трафика.

Шардирование окупается только тогда, когда у тебя есть план маршрутизации и отката. Сначала режь по самым независимым сегментам, потом переносы, потом отчёты.