Pub/sub

Redis pub/sub — fire-and-forget fan-out: publishers шлют в имена каналов; subscribers, онлайн в этот момент, получают сообщения. Нет persistence, acknowledgment и replay — пропущенные сообщения теряются.

					# терминал подписчика
SUBSCRIBE live:scores
# терминал издателя
PUBLISH live:scores '{"match":9,"score":"2-1"}'

# подписка по паттерну
PSUBSCRIBE notifications:*
				

| Pub/sub уместен | Не используйте pub/sub | |-----------------|------------------------| | Live UI updates | Payment или order workflows | | Эфемерные уведомления | Audit или event sourcing | | Низколатентный broadcast | Consumers могут быть offline | | Подсказки invalidation кэша | Нужна durability между регионами |

Pub/sub в классическом режиме занимает соединение Redis — в проде часто отдельное subscriber-соединение. Для durable нагрузок — Streams, внешний broker или outbox из БД.

На интервью: явно назовите гарантии доставки — at-most-once, без backlog для медленных consumers.

Типовые ошибки: pub/sub как job queue; нет reconnect/backoff; огромные payload на горячих каналах; критичная логика без идемпотентности.

Компромисс — минимальная latency broadcast vs нулевая durability: pub/sub для подсказок и live fan-out, не для работы, которая должна пережить рестарты или медленных consumers.

Чеклист:

• Подтвердите, что потеря сообщений допустима.
• Отдельное соединение для subscribers.
• Маленькие стабильные по схеме payload.
• Назовите durable альтернативу при росте требований.