← Все кейсы
ITоднушка / Кейс

Payment Service

API → Outbox → RabbitMQ → Worker → Webhook

Асинхронный микросервис обработки платежей. Клиент создаёт платёж через REST API, сервис сохраняет его и передаёт обработку в очередь, не заставляя пользователя ждать завершения операции.

01 API
→
02 Outbox
→
03 RabbitMQ
→
04 Worker
Payment #8 PENDING
12 500.00 RUB
async retry webhook
Задача

Обработать платёж
без ожидания клиента

Платёжные операции могут занимать время: внешний процессинг отвечает не мгновенно, а временные ошибки сети или сервиса нельзя считать окончательным результатом операции.

Поэтому API не выполняет всю обработку синхронно. Оно принимает запрос, сохраняет платёж и возвращает клиенту 202 Accepted.

202 Accepted запрос принят, а дальнейшая обработка выполняется асинхронно.
Как работает

Платёж проходит
несколько этапов

01

FastAPI

Принимает запрос на создание платежа и проверяет API Key и Idempotency-Key.

02

PostgreSQL

Сохраняет платёж и событие для последующей отправки в очередь.

03

Outbox

Надёжно передаёт событие из базы данных в RabbitMQ, не теряя сообщение.

04

Worker

Получает задачу из очереди и выполняет обработку платежа отдельно от API.

05

Webhook

После обработки сервис уведомляет внешний URL с повторными попытками.

Надёжность

Transactional Outbox защищает события

Платёж и событие для очереди записываются в PostgreSQL в рамках одной транзакции. Если операция сохранения прошла успешно, информация о необходимости обработки не теряется.

Отдельный publisher забирает необработанные события и отправляет их в RabbitMQ. После успешной публикации событие помечается как обработанное.

Outbox event published
Event payment.created
Status PENDING
Queue RabbitMQ
Delivery
retry DLQ async
ID
Идемпотентность

Повторный запрос
не создаёт второй платёж

Клиент передаёт уникальный Idempotency-Key. Если тот же ключ приходит повторно, сервис не создаёт новую платёжную операцию.

Это особенно важно для платежей: повторная отправка запроса из-за таймаута или проблем с сетью не должна приводить к двойному списанию.

Webhook

Внешний сервис
получает результат

Payment webhook Delivery
Status 200
Attempt 1
Retry 0
Result OK
payment_id UUID sent
status succeeded delivered
webhook_url HTTPS delivered
Обработка ошибок

Временная ошибка
не ломает весь процесс

01 Retry Повторная попытка
02 Backoff Exponential delay
03 RabbitMQ Message broker
04 DLQ Dead letter queue
Технологии

Что внутри

01 Python 3.12+
02 FastAPI REST API
03 SQLAlchemy Async ORM
04 PostgreSQL Database
05 RabbitMQ Message broker
06 FastStream Consumer
07 Alembic Migrations
08 Docker Containers
Результат

Платёжный сервис,
рассчитанный на асинхронную работу

Проект показывает, как построить отдельный сервис обработки платежей с очередью сообщений, идемпотентностью и механизмами повторной доставки.

Архитектура позволяет отделить публичный API от фоновой обработки и сделать отдельные этапы системы устойчивыми к временным сбоям.

Посмотреть код на GitHub →
Нужна автоматизация?

Давайте соберём систему, которая не развалится при нагрузке

Расскажите о задаче — спроектируем API, интеграции и фоновые процессы под ваш проект.

Обсудить задачу →