Postback delays: 5 мест, где обычно теряется время и как это чинить

Postback delays: 5 мест, где обычно теряется время и как это чинить

Задержка postback почти всегда сидит не в одном месте, а в цепочке: клик → трекер → сеть → MMP/advertiser → callback обратно. Если лаг нестабилен, сначала смотри на очереди и ретраи, потом на DNS, потом на сам endpoint.

— Неправильный timeout: слишком короткий даёт ложные timeout-ошибки, слишком длинный копит хвосты в очереди.
— 3xx/4xx на callback URL: часть интеграций молча ретраит, часть дропает конверсию.
— Слабый DNS или резолв через удалённый resolver: добавляет лишние сотни мс на каждый запрос.
— Агрегация и batching: если сеть шлёт события пачкой, задержка выглядит как «потеря», хотя это просто буфер.
— Rate limit на стороне приёмника: сначала всё зелёное, потом начинаются скрытые 429 и деградация.

Mitigation простой: держи отдельный лог по времени отправки и времени подтверждения, помечай retries, сравнивай p95/p99, а не только среднее. Для critical flow полезно ставить idempotency key, чтобы повторный postback не создавал дубль.

Если лаг растёт под нагрузкой — режь лишние hops, выноси callback endpoint ближе к трекеру и тестируй POST/GET отдельно. Главная ошибка — чинить «трекер», когда узкое место уже в сети или на стороне приёмника.