Как избежать дублирования отложенных писем при горизонтальном масштабировании сервиса?

Как исключить повторную отправку отложенных писем при горизонтальном масштабировании?

• область: распределённые системы, messaging
• ключевая проблема: конкуренция при отправке между несколькими инстансами
• решение 1 — идемпотентность: каждому email назначается уникальный ID, а отправка выполняется только один раз
• решение 2 — распределённая блокировка (например, Redis Redlock или Zookeeper), позволяющая лишь одному инстансу отправлять конкретное письмо
• решение 3 — гарантированное одноразовое извлечение из очереди (например, брокер с поддержкой точной доставки — Kafka или RabbitMQ с manual ack)
• решение 4 — сохранение статуса письма в БД с помощью атомарного флага отправки, чтобы разные инстансы транзакционно проверяли и изменяли состояние
• практическое применение: конкретный вариант выбирают с учётом архитектуры — сочетание брокера сообщений, идемпотентности и распределённой блокировки обеспечивает надёжность и масштабируемость
• итог: для исключения дублирования следует сочетать уникальные идентификаторы, распределённые лocks и атомарные обновления состояния

Так сохраняется согласованность при параллельной работе множества сервисов и исключается повторная отправка писем.

Подробный ответ

Основной ответ

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

Ключевые моменты

• Использование атомарных операций и механизма блокировок на уровне БД или распределённого кеша (например, Redis с RedLock) позволяет сервисам конкурировать за задачу, но не даёт нескольким инстансам одновременно начать отправку одного письма.
• Для каждого письма в БД следует хранить статус отправки (pending, sending, sent, failed) и уникальный идентификатор. До начала отправки экземпляр сервиса должен "захватить" письмо, атомарно обновив его статус и тем самым исключив параллельную отправку.
• Идемпотентность должна поддерживаться также на стороне SMTP-сервера или API отправки: если сервис по ошибке повторит запрос, внешний сервис не создаст дубликат, например при передаче уникального Message-ID.
• Дополнительно можно применить distributed task queue с гарантией однократного выполнения — например, RabbitMQ с подтверждениями или Apache Kafka с трансакционностью. В таком случае отложенные задачи хранятся централизованно и обрабатываются одним воркером.

Практический контекст

В прикладных системах на PostgreSQL 14+ такое поведение часто реализуют через поле статуса и SELECT FOR UPDATE, блокируя запись с письмом. Для масштабирования применяют Redis с RedLock, чтобы только один инстанс мог “захватить” задачу. В крупных системах основой становятся события: очередь сообщений (Kafka) и гарантированная обработка с помощью idempotent consumers позволяют избежать рассинхронизации и дублирования.