Idempotency: retry নিরাপদ করার উপায়
Payment request timeout হলে টাকা কাটল কি না? Idempotency retry-কে নিরাপদ করে। Idempotent method এবং idempotency key কীভাবে কাজ করে, জানুন।
একটি কাজ idempotent হয়, যদি বহুবার করলেও ফল একবার করার সমান হয়। মান ৫ সেট করা idempotent। মানের সাথে ৫ যোগ করা নয়।
কেন জরুরি
নেটওয়ার্ক ফেল করে। Client "১০০ টাকা চার্জ করো" পাঠাল, connection ছিঁড়ে গেল, আর সে জানল না server কাজটি করেছে কি না। কাজটি idempotent না হলে retry করলে গ্রাহক দুবার চার্জ হতে পারে। At-least-once দেয় এমন message queue-তেও একই সমস্যা।
HTTP method
GET, PUT ও DELETE idempotent হওয়ার কথা। POST ডিফল্টভাবে নয়, আর সেখানেই বাড়তি যত্ন দরকার।
Idempotency key
Client প্রতিটি যৌক্তিক কাজের জন্য একটি অনন্য key (যেমন UUID) বানিয়ে Idempotency-Key-এর মতো header-এ পাঠায়। Server:
- key খুঁজে দেখে।
- নতুন হলে কাজ করে, key ও response একসাথে সংরক্ষণ করে।
- আগেই থাকলে কাজ আবার না করে সংরক্ষিত response ফেরত দেয়।
Stripe-এর API এই pattern জনপ্রিয় করেছে।
বাস্তবায়নের টিপস
- Database-এ key-র ওপর unique constraint রাখুন, যাতে একসাথে আসা দুই retry দুজনেই জিততে না পারে।
- Key এবং business পরিবর্তন একই transaction-এ সেভ করুন।
- Key-কে "চলমান" চিহ্নিত করুন যাতে সমান্তরাল ডুপ্লিকেট অপেক্ষা করে বা conflict পায়।
- Key সীমিত সময় রাখুন (যেমন ২৪ ঘণ্টা)।
- একই key ভিন্ন body নিয়ে এলে প্রত্যাখ্যান করুন।
স্বাভাবিক idempotency
সম্ভব হলে কাজটিকে এমনভাবে ডিজাইন করুন যাতে এমনিই idempotent হয়: "status এক ধাপ এগাও" নয়, "status shipped করো"; অথবা অনন্য order ID রাখুন যাতে দ্বিতীয়বার insert ব্যর্থ হয়।
মূল কথা: ধরে নিন প্রতিটি request দুবার আসতে পারে, আর state বদলানো প্রতিটি call-এ idempotency key দিন।
System Design সিরিজের 14 নম্বর পর্ব (মোট ১৫)। আগের পর্ব: API gateway: microservice সিস্টেমের সদর দরজা.
