☀Объяснение:
Проблема:
Платёжные системы часто работают по протоколу at‑least‑once (гарантия доставки, но с возможными дублями). Сетевые сбои, перезапуски сервисов, таймауты могут привести к тому, что один и тот же успешный платёж уведомит ваш сервис дважды. Если ваша система просто списывает деньги по каждому вызову, клиент заплатит дважды. Скандал, возвраты, штрафы.
Решение — идемпотентность:
Обработчик платежа должен быть спроектирован так, чтобы повторная обработка того же платежа не меняла состояние системы (не списывала деньги повторно, не создавала дубликат заказа). Для этого нужно:
Каждому платежу присвоить уникальный идентификатор (например, payment_id).
При получении callback проверить, не обрабатывался ли уже этот payment_id.
Если обрабатывался — просто вернуть успех, ничего не делая.
Если нет — выполнить списание и запомнить payment_id в БД или кэше.
Пример кода (вариант B):
```python
def payment_callback(payment_id, amount):
# Ключ идемпотентности — payment_id
if redis.exists(payment_id):
return {"status": "already_processed"}
# Блокируем ключ на время обработки (например, 24 часа)
redis.setex(payment_id, 86400, "processed")
# Выполняем списание (только один раз)
debit_account(amount)
return {"status": "success"}
```
❌ Почему не другие варианты:
A (увеличить таймаут) — не решит проблему дублей, таймаут относится к ожиданию ответа, а не к повторным вызовам.
C (отключить повторные callback) — невозможно, внешний шлюз не позволит, да и это снизит надёжность (при сбое уведомление не придёт вообще).
D (ручное подтверждение) — убивает автоматизацию, требует персонала, не масштабируется.
Реальный кейс:
Интернет-магазин подключил платёжный агрегатор. В первые же дни у нескольких клиентов списалось вдвое больше. Причина — агрегатор в целях надёжности дублировал callback при таймауте подтверждения (магазин отвечал чуть дольше 3 секунд). После внедрения проверки по payment_id дубликаты перестали наносить урон.
Вывод для аналитика:
Идемпотентность — обязательное требование для интеграций с внешними системами, которые могут вызывать один и тот же коллбек несколько раз (а это почти все платёжные, SMS, email, push-сервисы). Аналитик должен явно прописывать в требованиях: «Обработчик должен быть идемпотентным, используя уникальный идентификатор события». 🎯
#INTEGRATION
