Brief #01 · Backend
Idempotent Payment API
Hard⏱ 15-20 ঘণ্টাশীঘ্রই
এমন একটা payment API, যেখানে খারাপ network যতবার খুশি retry করুক, customer এর টাকা কাটবে ঠিক একবারই।
Outline free · tracking সহ বানাতে Pro লাগবে
IBriefTeam এর পক্ষ থেকে
আমাদের checkout payment provider কে ডাকে, provider timeout দেয়, আর mobile app আবার চেষ্টা করে। গত মাসে ২১৪ জন customer এর টাকা দুইবার কেটেছে, আর support team এক সপ্তাহ ধরে refund দিয়েছে। Double charge অসম্ভব করে দাও, এমনকি app, network আর আমাদের নিজের server একসাথে গোলমাল করলেও।
যা বানাবে
- 1
POST /paymentsendpoint, যেটাIdempotency-Keyheader ছাড়া কাজ করে না, আর প্রতিটা key request এর hash সহ জমা রাখে। - 2Payment এর একটা state machine (created → processing → succeeded / failed), যার নিয়ম database নিজেই মানায়।
- 3পরীক্ষার জন্য একটা নকল payment provider, যাকে ইচ্ছামতো ধীর, unreliable বা duplicate callback পাঠানোর মতো বানানো যায়।
- 4একই key আর একই body এলে জমানো response ফেরত, একই key কিন্তু আলাদা body এলে 422।
- 5একটা load test, যেটা একই payment এর ১,০০০টা retry একসাথে পাঠায় আর প্রমাণ করে charge হয়েছে একবারই।
ধাপে ধাপে walkthrough
Walkthrough শীঘ্রই আসছে
এই project এর ধাপে ধাপে walkthrough, প্রতিটা ধাপে আসল output সহ, এখনো লেখা হচ্ছে। ততক্ষণ brief পড়ে নিজে চেষ্টা করতে পারো; walkthrough তৈরি হলে tracking চালু হবে।
শেষ হবে যখন
- Test suite এ retry, timeout বা crash এর কোনো combination এ দুইবার charge হয় না।
- একই key নিয়ে দুইটা request একসাথে এলে দুটোই provider পর্যন্ত পৌঁছায় না (row lock বা unique constraint দিয়ে, কপালের জোরে না)।
- Key ২৪ ঘণ্টা পরে মেয়াদোত্তীর্ণ হয়, আর পরিষ্কারের job টাও idempotent।
- README তে timeout এর পর retry এর পুরো ঘটনার একটা sequence diagram।
আরো এগোতে চাইলে
- প্রতি রাতে provider এর হিসাবের সাথে মিলাও, আর অমিল পেলে জানাও।
- Outbox pattern ব্যবহার করো, যাতে 'payment succeeded' event কখনো না হারায়।