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

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

Self-hosted трекер падает не от «большого трафика», а от узких мест в стеке. Сначала считай CPU wait, IOPS, latency БД и очередь вебхуков, потом уже масштабируй железо.

— База: разносите write-heavy и read-heavy запросы, держите индексы только под реальные фильтры, режьте лишние JOIN.
— Диск: под логи, БД и кэш — NVMe, иначе постбэки начнут ждать не сеть, а storage.
— Сеть: лимитируйте keep-alive, включайте gzip там, где это снижает payload без роста CPU.
— Очереди: все тяжёлые операции выносите из синхронного запроса — отчёты, антифрод, отправку постбэков.

Если трекер обслуживает много кликов, главная ошибка — пытаться лечить всё вертикальным апгрейдом. Гораздо полезнее поставить Redis для кэша, вынести агрегации в фоновые воркеры и разделить API-gate от аналитического контура. Тогда пиковая нагрузка не блокирует приём событий.

Проверяйте не только uptime, но и p95/p99 по ключевым эндпоинтам: клик, конверсия, выдача отчёта. Если один из них растёт, чистим логи, проверяем постбэки. Data-driven подход или работа вслепую — выбор за тобой.