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

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

Слабое место трекера обычно не в CPU, а в узких местах вокруг него: база, диск, сеть, очереди. Если лить объём без профилирования, то сначала растёт latency, потом сыпятся постбэки, и уже потом все смотрят на графики.

Базовый набор для high-load:
— разделяй web, worker и DB по разным узлам;
— для базы ставь быстрый SSD/NVMe, иначе логирование и агрегации душат запись;
— включай pool connections, иначе каждый запрос создаёт лишний overhead;
— кешируй тяжёлые read-only срезы и отчёты, а не весь трафик подряд.

Отдельно следи за очередями: конверсионные события, postback retries, антифрод-проверки и импорт кликов не должны идти в одном потоке. Когда фоновые задачи смешаны с боевым приёмом, ты получаешь очереди, таймауты и потерю атрибуции. Чистим логи, проверяем постбэки.

Перед масштабированием снимай метрики не только по нагрузке, но и по качеству обработки: p95/p99 latency, depth очереди, I/O wait, процент ретраев, время записи в БД. Data-driven подход или работа вслепую — выбор за тобой. Технический стек определяет потолок вашего ROI.