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

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

Когда один инстанс начинает тянуть и клики, и конверсии, и отчёты, узкое место обычно не в CPU. Чаще ломается связка: база, очереди, запись логов и внешние callback'и.

Рабочая схема — разделить контур по функции:
— write-path: приём клика, postback, запись в БД
— read-path: отчёты, фильтры, API-выгрузки
— async-path: тяжёлые события, дедуп, отправка наружу

Не смешивай всё в одной базе без лимитов. Для hot tables держи короткие индексы, отдельно выносишь агрегации и чистку мусора. Если отчёты начинают тормозить запись, значит read-path уже съедает write-path.

На практике sharding лучше делать не “по красоте”, а по предсказуемому ключу: GEO, project_id, offer_id или hash от click_id. Главное — чтобы один запрос всегда попадал в один shard, а не прыгал между ними. Иначе получишь дорогую маршрутизацию и сложную отладку.

Перед переносом обязательно проверь: где хранятся дедуп-ключи, как идут S2S retry, есть ли idempotency на postback, и что будет при partial failure. Если shard недоступен, система должна деградировать в read-only или буферизацию, а не терять конверсию.