System Design World

😎 Каждый бэкенд-инженер должен знать, как обрабатывать платежи

🍕 Проектируем ли мы сервис доставки еды или заказ такси, или любую другую платную услугу - везде можно углубиться в логику обработки платежа.
Его happy path, сбои.

‼️ В недавно вышедшей habr статье подробно расписаны состояния платежа и алгоритмы переходов.

Типовые статусы платежа
✅ Happy path: Инициирован, Обрабатывается, Успешно завершен
❌ Сбойные: Не выполнен, Ожидает повторной попытки, Возвращен, Отменен

🗓 Статусы предлагается менять в таблице с режимом записи append-only. Так чтобы видели всю историю изменений.

2️⃣ Проблемы с обработкой платежа делим на 2 типа:
1) Временные - когда можно сделать retry. К примеру, сетевая ошибка.
2) Существенные - не делаем retry. К примеру, недостаточно средств.
Наш главный сервис должен иметь логику по распознаванию таких проблем.

✨ Прикручиваем соответственно две очереди:
1) Retriable
2) Dead Letter Queue

🗝 Exactly-once Delivery
Если делаем повторную отправку из-за сетевой ошибки(❌ ), есть риск двойного списания🥺
К примеру, в ту сторону запрос с платежом прошёл. Обратно ответ не вернулся. А платёж успел осуществиться🤦
=> Поэтому приправляем нашу систему ключом идемпотентности реализуя тем самым семантику доставки exactly-once.

🔥 - Хорошая выжимка. Ожидаю больше подобных рецензий

Please open Telegram to view this post

VIEW IN TELEGRAM

www.tg-me.com/jp/System Design World/com.system_design_world/252

3.0K viewsВладимир в IT, Apr 29 at 12:09

😎 Каждый бэкенд-инженер должен знать, как обрабатывать платежи

🍕 Проектируем ли мы сервис доставки еды или заказ такси, или любую другую платную услугу - везде можно углубиться в логику обработки платежа.
Его happy path, сбои.

‼️ В недавно вышедшей habr статье подробно расписаны состояния платежа и алгоритмы переходов.

Типовые статусы платежа
✅ Happy path: Инициирован, Обрабатывается, Успешно завершен
❌ Сбойные: Не выполнен, Ожидает повторной попытки, Возвращен, Отменен

🗓 Статусы предлагается менять в таблице с режимом записи append-only. Так чтобы видели всю историю изменений.

2️⃣ Проблемы с обработкой платежа делим на 2 типа:
1) Временные - когда можно сделать retry. К примеру, сетевая ошибка.
2) Существенные - не делаем retry. К примеру, недостаточно средств.
Наш главный сервис должен иметь логику по распознаванию таких проблем.

✨ Прикручиваем соответственно две очереди:
1) Retriable
2) Dead Letter Queue

🗝 Exactly-once Delivery
Если делаем повторную отправку из-за сетевой ошибки(❌ ), есть риск двойного списания🥺
К примеру, в ту сторону запрос с платежом прошёл. Обратно ответ не вернулся. А платёж успел осуществиться🤦
=> Поэтому приправляем нашу систему ключом идемпотентности реализуя тем самым семантику доставки exactly-once.

🔥 - Хорошая выжимка. Ожидаю больше подобных рецензий