TG Telegram Group & Channel
System Design World | United States America (US)
Create: Update:

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

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

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

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

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

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

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

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

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

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

🍕 Проектируем ли мы сервис доставки еды или заказ такси, или любую другую платную услугу - везде можно углубиться в логику обработки платежа.
Его 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


>>Click here to continue<<

System Design World






Share with your best friend
VIEW MORE

United States America Popular Telegram Group (US)