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

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

Self-hosted трекер умирает не от «плохого кода», а от узких мест в I/O, БД и очередях. Сначала фиксируем базу: отдельный диск под логи и базу, SSD с запасом по write endurance, swap — только как аварийный буфер.

Дальше смотрим на БД: индексы по source, campaign_id, click_id и времени события обязательны. Если таблицы событий растут без партиционирования — запросы начинают съедать CPU и блокировать запись. Для высоких объёмов полезны read-replica и вынесенный аналитический контур, чтобы отчёты не душили приемку кликов.

Третья точка — веб-слой и очереди. Nginx держит TLS и буферизацию, приложение не должно писать в базу синхронно на каждом событии. S2S-приём лучше разгружать через очередь: сначала принять, потом обработать, потом отправить постбэк. Это снижает потери при всплесках и упрощает ретраи.

Отдельно проверь лимиты: file descriptors, conntrack, backlog, max connections в БД и таймауты между сервисами. Если логи растут быстрее, чем ты их читаешь, автоматизируй ротацию и алерты по latency, error rate и queue depth. Чистим логи, проверяем постбэки. Технический стек определяет потолок вашего ROI.