Модуль 6. Границы применимости: Streams vs Kafka vs RabbitMQ и чек-лист выбора

Цель модуля: превратить знание Redis-очереди в проектное решение: честно сравнить три брокера по эксплуатационным осям, пройти чек-лист «наша очередь на Redis — осознанно или временно» и составить план миграции, если очередь переросла Redis.

Перед началом: все предыдущие модули курса; курсы Kafka и RabbitMQ трека — для сравнения с противоположного конца. Трудоёмкость: ~6–8 ч (разбор 3 ч · практика/ревью 4 ч).

📖 6.1. Сравнение по эксплуатационным осям, а не по фичам

Таблицы «фича vs фича» бесполезны — почти всё есть у всех. Работает сравнение по осям, которые вы будете защищать на ревью:

📖 6.2. Когда очередь на Redis — осознанное решение

Три честных сценария (не «сэкономили на брокере», а «здесь он и не нужен»):

1. Очередь — часть сервиса, который уже пользуется Redis. Кеш, локи, rate-limiter живут рядом; очередь на 1000–100 000 сообщений в день с retention «пару часов» — постольку-поскольку. Отдельный брокер тут не несёт смысла;
2. Задержка важнее ретеншена. Realtime-сигналы (обновления в UI, инвалидации), где обработка через секунды, а история не нужна: Redis отдаёт мкс-латентность, Kafka — нет и не должна;
3. Быстрый старт и очевидная эксплуатация. Нет дежурного на Kafka, нет партиций и ISR; одна галочка в Terraform — и очередь работает. Осознанная плата: хрупкость к перерастанию (см. §6.3).

Осознанность = вы можете вслух произнести цену: «мы теряем до секунды при отказе, стрим живёт в RAM, поток один на стрим, и когда вырастет до миллионов сообщений/сутки — переедем на Kafka».

📖 6.3. Чек-лист «пора уезжать с Redis»

Пятёрка стоп-сигналов — любой сработавший требует плана миграции, а не тюнинга:

• Объём: used_memory стримов подошёл к 50 % maxmemory (очередь начинает конкурировать с кешем — инцидент §5.4 стоит ждать);
• Пропускная способность: устойчиво > 5–10 тыс. msg/s на стрим, и шардирование по {orders:N} переросло 20–30 стримов;
• Ретеншен: нужна история «дни», а не «часы» (replay, аудит, догон нового консьюмера с нуля);
• Режимы: нужен exactly-once/транзакции, компакция, десятки тысяч независимых топиков — Redis этого не умеет;
• Надёжность: потеря секунды стала неприемлемой для бизнеса (деньги, юридически значимые события) — сходите за Kafka/Rabbit.

📖 6.4. План миграции: как уехать, не сломав обработку

Миграция «очередь с Redis → Kafka» — это не замена клиента, а смена контракта (Streams → топик/партиции). Рабочий порядок:

1. Двойная запись (dual-write): продюсер пишет и в Redis, и в Kafka;
2. Двойное чтение с первенством: консьюмер читает из Redis, Kafka — в режиме «удочерения» (сверка, реплей в отдельный лог); метрики сходятся → переключаем первенство;
3. Оффсеты и идемпотентность: ваш IdempotentHandler из Модуля 3 — уже половина миграции: повторная доставка из Kafka не нова;
4. Выключаем Redis-путь после N суток нулевых расхождений; стрим оставляем read-only на месяц — «на посмотреть»;
5. Ретроспектива: что в дизайне событий оказалось привязано к Redis (ID сообщений как бизнес-ключ — типовая ловушка), что чинить.

Миграция в другую сторону (Kafka → Redis) существует тоже — для очередей, которые «всего лишь уведомления», но выросли слишком дорого: та же таблица, прочитанная справа налево.

📖 6.5. Итоговое решение: шаблон ADR

Курс требует не «мнения», а артефакта. Напишите ADR (Architecture Decision Record) на 1 страницу по своему кейсу:

markdown
# ADR: очередь <название> на Redis Streams

## Контекст
- Профиль нагрузки: <N msg/s, пики, размер записи>
- Требования: <потери, задержка, ретеншен, порядок>

## Решение
Redis Streams: стрим {orders:0..N}, группа billing, MaxLen ~ <...>,
noeviction, отдельный инстанс <или общий с кешем — обосновать>

## Цена решения (осознанная)
- Потери: <...> при отказе; митигация: WAIT/идемпотентность
- Потолок: <...> — стоп-сигналы §6.3 и пороги переезда

## План переезда
- Триггеры: <метрика-сигнал>
- Схема: dual-write → двойное чтение → выключение (§6.4)

## Ссылки
- Модули курса, тесты нагрузки, дашборд

💻 Практика

1. Защита ADR (ревью-игра): обменяйтесь ADR с коллегой/другом; ревьюер обязан найти хотя бы один стоп-сигнал §6.3 в контексте или отсутствующий порог переезда. Вы — защищаете или фиксируете правку;
2. Бенчмарк на пальцах: на стенде прогоните 100 тыс. XADD (по 1 КБ) при MaxLen ~ и без; замерьте р99 XADD, потребление памяти, размер AOF. Занесите в ADR цифры — свои, не из таблицы;
3. Смоделируйте деградацию: включите maxmemory 128mb на стенде и доведите очередь до 60–70 % — посмотрите на панели, каким будет ваш чек-лист действий дежурного до срабатывания OOM (Модуль 5, §5.5);
4. Финальный «мостик через трек»: возьмите любой из стоп-сигналов §6.3 и распишите первые два шага миграции (§6.4) на своем кейсе — это уже exercise для Kafka-курса.

🧩 Quiz "Проверь себя"

✅ Итоги модуля

🎓 Итоги курса

Redis как брокер — это не «маленькая Kafka» и не «дешёвый RabbitMQ». Это полноценный инженерный выбор с ясными границами:

• Механика — Streams, группы, pending и claim (Модули 1, 3) — даёт at-least-once не хуже старших брокеров;
• Цена — память-ретеншен, однопоточность, асинхронная репликация (Модули 2, 5) — то, что вы обязаны произнести вслух перед продакшеном;
• Эксплуатация — мониторинг и инцидент-разбор (Модули 4, 5) — превращает «работает» в «переживает»;
• Граница — ADR (Модуль 6) — главный артефакт курса: решение, которое можно защитить, измерить и вовремя пересмотреть.

Дальше — курсы Kafka и RabbitMQ трека: та же дисциплина ответов (гарантии, отказы, метрики, инциденты) на больших системах.