Очередь уведомлений росла, пока падал только один тип событий

Сервис отправлял push, email и SMS через общую очередь с одним consumer-пулом. В пике маркетинговой рассылки лаг очереди начал расти, и команда первым делом увеличила число воркеров — не помогло.

Проблема была не в throughput, а в том, что SMS-провайдер отвечал с задержкой 8–10 секунд на часть запросов, и воркеры простаивали на синхронном HTTP-вызове к нему. Push и email обрабатывались за миллисекунды, но делили очередь и пул с медленными SMS — быстрые сообщения стояли за медленными.

Решение — разделить очередь по типу канала и дать каждому типу свой пул с таймаутом под его реальную задержку. SMS получил отдельный небольшой пул с коротким таймаутом и ретраем, push и email остались в общем быстром пути.

Спросят следом: как посчитать нужное число воркеров для каждой очереди отдельно. Формула простая — throughput = workers / avg_processing_time на каждый канал отдельно, а не усреднённо по всей очереди. Смешанная очередь с разным avg_processing_time ломает эту формулу в принципе — отсюда и решение разделить, а не пересчитать.

Одна общая очередь для разных по природе задержки каналов — то, что выглядит простым в начале и ломается под нагрузкой первым.

Тренажёр: 900+ вопросов и задач, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки