Self-hosted трекер под нагрузкой: где умирает сервер и как это чинить

Self-hosted трекер под нагрузкой: где умирает сервер и как это чинить

Первый узкий слой — база. Если трекер пишет все клики, постбэки и редиректы в одну БД без индексов по campaign_id, sub_id и created_at, ты получаешь очередь, а не аналитику. Разносите hot-path: отдельные таблицы под сырые события, отдельные — под агрегаты, кэш для частых выборок.

Дальше I/O. Под высокой нагрузкой чаще всего упираются не в CPU, а в диск и сетевые round-trip. Логируй асинхронно, режь синхронные записи, выноси тяжелые отчеты в фоновые джобы. Если в пике растет latency редиректа, сначала смотри в очередь записи и время ответа БД, а не в график загрузки ядер.

На уровне приложения держи API-гейты и S2S-постбэки короткими: минимум вычислений, максимум предсказуемости. Любая валидация, антифрод и нормализация параметров — после приема события, а не в критическом пути. Для сплит-тестов и ретаргета используй кэшированные правила, иначе каждое обращение будет бить по throughput. ⚙️

Финальный слой — наблюдаемость: метрики p95/p99 по редиректу, длина очереди, lag репликации, ошибки постбэков, процент дубликатов. Без этого ты не увидишь, где именно трекер начинает деградировать. Чистим логи, проверяем постбэки. Data-driven подход или работа вслепую — выбор за тобой.