5. Надежность платежей: «Как решалась проблема идемпотентности в gRPC?»

Условие

5. Надежность платежей: «Как решалась проблема идемпотентности в gRPC?»

Цель интервьюера: Платежи — самая опасная область для дублей (Double Spending).

Возможный вопрос: «Запрос на оплату ушел через gRPC, но упал по таймауту (DEADLINE_EXCEEDED). Списались ли деньги — неизвестно. Что делает модуль оплаты?»

Как ответить: «В финансовом транзакционном контексте любой повторный запрос обязателен с Idempotency Key:

1. В метаданных gRPC-запроса (metadata=((‘x-idempotency-key’, key_uuid),)) мы всегда передавали уникальный ключ транзакции.
2. При получении DEADLINE_EXCEEDED клиент мог безопасно делать Retry с тем же ключом.
3. Сервис эквайринга проверял наличие этого ключа в своей БД / Redis и либо возвращал статус уже проведенной транзакции, либо обрабатывал ее впервые.»

Ответ

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

Сам заголовок x-idempotency-key ничего не гарантирует: это согласованный контракт приложения, не встроенное свойство gRPC. Ключ связывают с пользователем, типом операции и неизменным payload; конфликт параметров отклоняют. Уникальное ограничение и состояния pending/succeeded/failed защищают от одновременных повторов. Внешнему эквайрингу передают стабильный идентификатор, а неизвестный результат сверяют по статусу и webhook. Redis без согласованной долговечности и достаточного срока хранения не должен быть единственной защитой от повторного списания. Безопасность retry обеспечивается всей схемой.