Почему ваш RabbitMQ упадёт: реальный кейс для системного аналитика

Что происходит, когда очередь сообщений выглядит пустой, а нода RabbitMQ уже задыхается от гигабайт данных? В этом выпуске разбираем реальную аварию, где сообщения, отложенные через Delayed Message Exchange, оказались «невидимками», и стремительно забивали память брокера, что привело к внезапной остановке всей системы доставки.

Telegram-канал сообщества: https://t.me/getanalysts

Мы обсуждаем, как массовые рассылки персонализированных писем превратили RabbitMQ в тяжелое хранилище объектов, для которого он архитектурно не предназначен. Вы узнаете, почему важно проектировать брокер как «контракт доставки», а не просто как «трубу» между сервисами.

Выпуск актуален для системных аналитиков и архитекторов, которые проектируют интеграции через брокеры и отвечают за отказоустойчивость на проде. Также это отличный материал для подготовки к собеседованиям System Design Interview, где часто спрашивают про гарантии доставки, профили нагрузки и работу очередей в условиях аварий.

Тайм-коды эпизода:

00:00 | Заставка
00:18 | Введение и знакомство со спикером
01:36 | Для каких задач выбрали RabbitMQ
03:12 | Как работают интеграции с внешними системами через брокер
05:03 | DMX (Delayed Message Exchange) — задача, которая положила RabbitMQ
07:21 | Где в логах и мониторинге видны признаки падения RabbitMQ
08:27 | Последствия аварии и объём потерянных сообщений
11:52 | Что входит в payload сообщения RabbitMQ
14:00 | Порядок действий после падения RabbitMQ и почему не стоит проталкивать сообщения руками
16:50 | Инструменты аналитиков для работы с RabbitMQ
18:25 | Инфраструктура RabbitMQ: ноды
19:45 | Рекомендации по проектированию взаимодействия с RabbitMQ