Как не положить self-hosted трекер под нагрузкой: серверный чек-лист без лишнего шума

Как не положить self-hosted трекер под нагрузкой: серверный чек-лист без лишнего шума

Трекер умирает не от «большого трафика», а от узких мест: CPU на парсинге, I/O на базе, очередь на постбэках, лимиты connection pool. Сначала смотри не на VPS «побольше», а на профиль нагрузки: RPS на клик, долю редиректов, частоту S2S-вызовов, размер логов.

База — первый кандидат на оптимизацию: индексы только под реальные запросы, без мусора; write-heavy таблицы выноси отдельно; автоочистку и партиционирование ставь до того, как диск начнёт задыхаться. Для тяжёлых инсталляций полезны отдельные диски под БД и логи, чтобы не делить один I/O-поток между всем стеком.

На уровне приложения режь синхронщину: постбэки, вебхуки, отправку логов и статистику лучше уводить в очередь, а не держать в request path. Кешируй то, что не требует точной мгновенной консистентности: маппинги офферов, настройки кампаний, частотные проверки. И обязательно ставь таймауты, ретраи с backoff и лимиты на параллельные запросы к внешним API.

Мониторинг без метрик — работа вслепую. Следи за CPU steal, iowait, latency БД, длиной очереди, error rate по постбэкам и временем ответа редирект-цепочки. Чистим логи, проверяем постбэки. Если система масштабируется только вертикально — у тебя не стек, а одна точка боли. Data-driven подход или работа вслепую — выбор за тобой.