Когда Kafka — не панацея: Sharded Task Queue от Яндекса
Когда Kafka — не панацея: Sharded Task Queue от Яндекса На канале сейчас рассказываю про Kafka (тык1, тык2) и её использовании при построении ETL-процессов. Поэтому сегодня решил разобрать доклад, где Kafka оказалась недостаточным решением — про внутреннюю систему Яндекса Sharded
25-09-2025 09:32 (МСК)
Когда Kafka — не панацея: Sharded Task Queue от Яндекса На канале сейчас рассказываю про Kafka (тык1, тык2) и её использовании при построении ETL-процессов. Поэтому сегодня решил разобрать доклад, где Kafka оказалась недостаточным решением — про внутреннюю систему Яндекса Sharded Task Queue (STQ). 🔹 Что такое STQ? Это месседж-брокер, а не классический сервер очередей (вроде Kafka или RabbitMQ). Основная цель: надёжное выполнение отложенных задач с произвольной точностью (например, отправить уведомление через 40 минут, или месяц или год). Система не сохраняет порядок задач, что критически важно для отложенных операций. 🔹 Как рождалось решение. Авторы не стали сразу пилить монстра. Они честно говорят, что решали проблему одну за другой, как и бывает в реальных задачах. Это показывает инженерную работу, а не просто презентацию готового результата. В итоге сложились следующие требования: Базовые: Произвольная точность выполнения, ретраи, независимость от падений сервисов. Инфраструктурные: Долгосрочное хранение, наблюдаемость, масштабируемость для высоких нагрузок и кросс-платформенность (поддержка разных языков программирования). Именно эти требования сразу отсекли простые варианты вроде Cron и заставили искать специализированное решение. 🔹 Сравнение с Kafka и RabbitMQ Главный вывод: классические брокеры — это про порядок (FIFO), а отложенные задачи — про произвольный доступ ко времени выполнения. Попытка сделать «отложенную очередь» на Kafka — это костыли. STQ же хранит задачи как база данных с индексами, что позволяет гибко двигать их по времени. Это ключевое архитектурное отличие, продиктованное требованиями. 🔹 Результат Система стала критической инфраструктурой для 700+ микросервисов (такси, доставка, банк) с пиковой нагрузкой под 150k RPS. Философия — «разработчик не должен думать о проблемах очередей», и судя по отзывам, у них получилось. 🔸 Что огорчило Информационный вакуум. Кроме этого видео и пары упоминаний в вакансиях, подробной информации не нашел. Возможно, есть ещё пару докладов, но в названии и контексте там не указана STQ. Очень жаль, что такая крутая инженерная разработка не имеет публичной документации. Хочется заглянуть под капот! ✅ Итог Отличный пример, что нет серебряной пули. Инструменты вроде Kafka — мощные, но для узких задач (как отложенные выполнения) часто нужны специализированные решения. Ссылка на доклад: https://vkvideo.ru/video-17796776_456241737?pid=152308462 💬 А Вы сталкивались с задачами, где классические брокеры не подходили? Либо когда публично-известное решение обладало рядом существенных недостатков и нужно было реализовывать собственное решение? Интересно обменяться кейсами! #ITИнсайты