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

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

Self-hosted трекер падает не из-за «слабого VPS», а из-за неверного распределения нагрузки. Сначала режем узкие места: CPU на обработке редиректов, диск на записи логов, сеть на постбэках. Если всё крутится на одном узле — получаешь очереди, таймауты и потерю событий.

Рабочая схема:
— веб-сервер и база данных разнесены;
— логи пишутся на быстрый SSD, не на сетевое хранилище;
— кэш и очереди вынесены отдельно, чтобы не душить БД;
— тяжёлую аналитику и агрегации уводим в фоновые задачи.
Для трекера важнее стабильная задержка, чем пиковая частота CPU. Один медленный запрос в момент клика = минус конверсия.

Дальше смотри на I/O wait, а не только на загрузку процессора. Если база упирается в диск, добавляй буферизацию, индексируй поля под реальные фильтры и режь лишние записи в логах. Постбэки и API-гейты лучше обрабатывать асинхронно, с очередью и ретраями, иначе один внешний таймаут начинает валить весь пайплайн.

Перед масштабированием делай сплит-тест инфраструктуры: один поток — на текущей схеме, второй — на разгруженной архитектуре. Сравнивай не только TPS, но и процент потерянных событий, latency редиректа и время ответа postback endpoint. Data-driven подход или работа вслепую — выбор за тобой.