Hard&Soft Skills

АНАТОМИЯ ФИЧИ: Как Stripe не списывает деньги дважды

Клиент отправил платёж, а ответа нет: оборвалась сеть или сработал timeout. Списались деньги или нет, неизвестно, а повтор может списать их второй раз.

Идемпотентность – свойство операции: повторный вызов даёт тот же эффект, что первый, и деньги не спишутся дважды. Для этого клиент кладёт в каждый запрос уникальный ключ идемпотентности. Когда запрос приходит повторно, сервер видит знакомый ключ и понимает, что это дубль, а не новый платёж.

🔬 **Что видно снаружи**

В основном API Stripe (v1) ключ передают в заголовке Idempotency-Key.

Повтор с тем же ключом получает тот же код и то же тело ответа, даже если в первый раз был 500.

⚙️ **Что сервер запоминает по ключу**

Stripe хранит не факт «запрос был», а результат первого вызова, который дошёл до выполнения.

Повтор пришёл, пока первый ещё выполняется, – ответ 409 Conflict. С тем же ключом пришли другие параметры – ошибка.

Слой перед бизнес-логикой ищет ключ в хранилище. Нет ключа – ставит запись с блокировкой, выполняет платёж и сохраняет ответ. Есть – отдаёт сохранённое.

🧬 **Почему ключ даёт клиент и чем за это платят**

Сервер не отличит повтор от второго настоящего платежа: запросы одинаковые. Только клиент знает, отправил он тот же платёж ещё раз или хочет заплатить второй раз, поэтому ключ генерирует он.

Хранить ответы вечно дорого: по документации ключ можно удалить, когда ему исполнилось 24 часа, и повтор после этого создаст новый платёж.

Платит интегратор. Ключ записывайте до отправки: сервис упал, после рестарта сделал новый ключ, и защиты нет.

Повтор после 500 вернёт тот же 500, поэтому что случилось с платежом, приходится выяснять отдельно.

🤝 **Та же задача без заголовка-ключа**

🔹 Kafka, idempotent producer: брокер помнит ID продюсера и номер сообщения в партиции и отбрасывает дубли. Номер ставит сама система, но защита живёт одну сессию продюсера.
🔹 PUT на ресурс с ID, который выбрал клиент: повтор записывает то же состояние, ответы хранить не нужно. Подходит, пока операция звучит как «установить», а не «сделать».
🔹 Уникальный индекс в базе: INSERT ... ON CONFLICT DO NOTHING по номеру заказа. Дубль отсекается по бизнес-ключу, но первый ответ повтору никто не вернёт.

Все варианты решают одну задачу: узнать повтор. Для этого у операции нужна метка, одинаковая у оригинала и у повтора, и система должна помнить её, пока повтор ещё может прийти.

В Stripe метку придумывает клиент – это ключ, и сервер помнит его не меньше суток. В Kafka метку ставит сама система – номер сообщения, но помнит её только до перезапуска продюсера. В PUT метка – ID ресурса, в уникальном индексе – номер заказа, и обе живут, пока лежит запись.

Когда проектируют идемпотентность своего API, решают именно эти два вопроса: кто ставит метку и сколько её хранить. Заголовок Idempotency-Key – лишь один из способов передать метку.

📚 **Что почитать:**

"Idempotent requests" – документация Stripe API

"Implementing Stripe-like Idempotency Keys in Postgres" – Brandur Leach, 2017

🎬 Запись Конклава #49 уже на YouTube

«Как инженеру проверить идею продукта до первой строчки кода?»

Если вы не оказались вчера среди 70 счастливчиков, которые смотрели Конклав онлайн, – ловите ссылку на запись:
https://www.youtube.com/watch?v=sbGGzbuuUFA

Чтобы не пропускать записи, подключите нашего бота: @HardSoftSkills_Assistant_bot
Бот сам пришлёт ссылку на запись каждого ивента, на который вы зарегистрировались.

Почему оценки сроков врут и что техлид может сделать, чтобы они были точнее

Проблема в том, что в оценке сроков почти всегда ошибаются в одну сторону.

📐 Почему ошибки складываются в опоздание

Если подзадачу оценили в три дня, в лучшем случае она займёт два. В худшем – две недели, потому что вылезло то, чего не знали заранее.

Поэтому, когда складывают двадцать подзадач, ошибки не гасят друг друга, а только добавляют опоздание.

Кроме того, если на какой-то задаче время сэкономили, до финиша оно обычно не доходит. Работа часто растягивается на всё время, которое на неё отвели, а если задачу и сделали раньше, следующая, как правило, всё равно начинается по плану.

А опоздание всегда тянет за собой следующие задачи: если API на бэкенде не готов, фронтенд-разработчик сидит и ждёт.

И в декомпозиции есть только та работа, о которой команда уже знает.

В плане стоит «интеграция с платёжным провайдером – три дня», и ее действительно можно реализовать за три дня. А на деле оказывается, что доступы выдаёт другая команда, и их приходится ждать неделю.

📅 Что ломается, когда вместо разброса называют одну дату

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

А бизнесу нужна одна дата, и чем быстрее – тем лучше. Поэтому берут какое-то одно число из оценки разработчика, и в этот момент теряется самое важное – то, насколько он не уверен.

Потом дата перестаёт быть оценкой и становится обещанием. Под неё маркетинг планирует кампанию, продажи говорят клиенту «к такому-то числу будет».

А потом в реализации возникают проблемы, сроки срываются, и крайний – тот, кто "пообещал" конкретную дату.

🛠 Что делать техлиду

🔸 Давай две даты, а не одно число: к какой сделаете с шансом пятьдесят на пятьдесят и к какой – почти наверняка. Под позднюю дату ставь то, что нельзя сдвинуть, например то, что пообещали клиенту. Под раннюю – то, что сдвинуть можно.

🔸 Держи бизнес в курсе того, где команда сейчас: ближе к ранней дате или к поздней. Если договорились об этом с самого начала, «идём к поздней дате» – уже не плохая новость, а как раз то, о чём обещали сообщать.

Перед оценкой следующего проекта выгрузи из трекера десять–пятнадцать закрытых задач, похожих на новые, и посчитай, насколько факт отличался от оценки.

Это и есть запас команды, а не процент, который закладывают по привычке.

📚 Что почитать:

"Why software projects take longer than you think: a statistical model" – Erik Bernhardsson, 2019
"When Will It Be Done?" – Daniel Vacanti, 2020