Какие архитектурные подходы можно использовать при разделении API-сервиса и воркера?

Разделение API и воркеров — это про разные SLO: API важна минимальная задержка, воркерам — пропускная способность и надежная обработка.

Определение: Воркер — процесс/сервис, который забирает задания из очереди и выполняет их вне контекста входящего HTTP-запроса.

1) Базовый подход: API + очередь + воркеры

1. API принимает запрос.

2. Делает минимально необходимое синхронно (проверки, транзакция, сохранение “заказа”).

3. Публикует задание в очередь.

4. Воркер потребляет задание и выполняет тяжелую часть.

Почему это хорошо:

• API отвечает быстро (не держит соединение во время “долгой работы”).

• Воркеры можно масштабировать независимо от API.

• Появляются ретраи, DLQ, идемпотентность.

2) Подходы к согласованности и надежности

1. Outbox pattern (рекомендуется, если важно “не потерять сообщение”)

• API пишет бизнес-данные и “outbox-событие” в одну БД-транзакцию.

• Отдельный паблишер читает outbox и публикует в брокер.

2. At-least-once обработка (типично для очередей)

• Сообщение может прийти повторно, поэтому воркер должен быть идемпотентным.

3. Saga / choreography (если задач много и есть шаги)

• Длинная операция раскладывается на шаги с событиями и компенсирующими действиями.

3) Контракты заданий и модели данных

• Минимизируйте payload: передавайте task_id/entity_id, а детали берите из БД.

• Версионируйте формат сообщения (например, поле version).

• Добавляйте метаданные: trace_id, created_at, attempt.

4) Пример постановки задачи (упрощенно)

# API: положили "задачу" в брокер (псевдокод)
message = {"task": "send_email", "user_id": 42, "trace_id": trace_id}
broker.publish("jobs", message)

Вывод

Разделяйте API и воркеры, когда есть долгие операции, внешние интеграции или пики нагрузки: очередь дает буферизацию, воркеры — независимое масштабирование и контроль надежности.