CRUD অ্যাপে ডুপ্লিকেট রেকর্ড প্রতিরোধ: ব্যবহারিক প্রতিরক্ষা

ডুপ্লিকেট রেকর্ড কী এবং কেন ঘটে\n\nডুপ্লিকেট রেকর্ড হল যখন আপনার অ্যাপ একই জিনিস দুইবার সেভ করে ফেলে। সেটা হতে পারে একই চেকআউটের জন্য দুইটি অর্ডার, একই ডিটেইলস নিয়ে দুইটি সাপোর্ট টিকিট, অথবা একই সাইনআপ ফ্লো থেকে দুইটি অ্যাকাউন্ট। CRUD অ্যাপে ডুপ্লিকেট সাধারণত আলাদা রো হিসেবে থাকে, কিন্তু ডেটাকে সামগ্রিকভাবে দেখলে ঠিক নয়।\n\nঅধিকাংশ ডুপ্লিকেট শুরু হয় সাধারণ আচরণ থেকেই। কেউ Create দুইবার ক্লিক করে কারণ পেজ ধীর মনে হচ্ছে। মোবাইলে ডবল-ট্যাপ খোঁজেই মিস হওয়া সহজ। এমনকি যত্নশীল ব্যবহারকারীরাও আবার চেষ্টা করবে যদি বাটন এখনও সক্রিয় দেখায় এবং স্পষ্ট কিছু ঘটছে বলে না দেয়।\n\nতারপর আছে নোংরা মাঝামাঝি: নেটওয়ার্ক এবং সার্ভার। একটি রিকোয়েস্ট টাইমআউট হতে পারে এবং স্বয়ংক্রিয়ভাবে রিট্রাই হতে পারে। ক্লায়েন্ট লাইব্রেরি যদি মনে করে প্রথম চেষ্টা ব্যর্থ হয়েছে, তাহলে এটি একটি POST পুনরায় পাঠাতে পারে। প্রথম রিকোয়েস্ট সফল হতে পারে, কিন্তু রেসপন্স লস্ট হয়ে গেলে ব্যবহারকারী আবার চেষ্টা করে এবং দ্বিতীয় কপি তৈরি হয়।\n\nআপনি এক লেয়ারে এটা সমাধান করতে পারবেন না কারণ প্রতিটি স্তর কেবল গল্পের একটা অংশই দেখে। UI দুর্ঘটনাজনিত ডবল সাবমিট কমাতে পারে, কিন্তু খারাপ কনেকশনের পুনরায় পাঠ থামাতে পারে না। সার্ভার রিপিট সনাক্ত করতে পারে, কিন্তু এটি চিহ্নিত করার জন্য নির্ভরযোগ্য উপায় চায় যে "এটা আবার একই create।" ডাটাবেস নিয়ম আরোপ করতে পারে, কিন্তু সেই ক্ষেত্রে আপনাকে নির্দিষ্ট করতে হবে "একই জিনিস" মানে কি।\n\nলক্ষ্য সহজ: একই রিকোয়েস্ট দুইবার ঘটলেও creates নিরাপদ রাখুন। দ্বিতীয় চেষ্টা নো-অপ হওয়া উচিত, একটি পরিষ্কার “আগেই তৈরি হয়েছে” রেসপন্স হওয়া উচিত, অথবা একটা নিয়ন্ত্রিত কনফ্লিক্ট — না যেন দ্বিতীয় রো।\n\n## কোথায় ডুপ্লিকেট হয় (ক্লায়েন্ট, নেটওয়ার্ক, সার্ভার)\n\nঅনেক দল ডুপ্লিকেটকে ডাটাবেস সমস্যা হিসেবেই দেখে। বাস্তবে, ডুপ্লিকেট প্রায়ই আগেই জন্ম নেয়, যখন একই create অ্যাকশন একাধিকবার ট্রিগার হয়।\n\n### ক্লায়েন্ট‑সাইড: ব্যবহারকারী দুইবার সাবমিট করে\n\nএকজন ব্যবহারকারী Create ক্লিক করে এবং কিছুই ঘটছে না মনে হলে আবার ক্লিক করে। অথবা তারা Enter চাপে, তারপর দ্রুত বাটনে ক্লিক করে। মোবাইলে দুইটি দ্রুত ট্যাপ, ওভারল্যাপিং টাচ ও ক্লিক ইভেন্ট, বা একটি জেসচারের ফলে ডাবল রেজিস্ট্রেশন হতে পারে।\n\n### নেটওয়ার্ক ও ট্রান্সপোর্ট: রিকোয়েস্ট পুনরায় পাঠানো হয়\n\nব্যবহারকারী শুধু একবার সাবমিট করলেও, নেটওয়ার্ক রিকোয়েস্টকে পুনরায় পাঠাতে পারে। টাইমআউট রিট্রাই ট্রিগার করতে পারে। একটি অফলাইন অ্যাপ "Save" কিউ করে পুনরায় সংযোগে পাঠাতে পারে। কিছু HTTP লাইব্রেরি নির্দিষ্ট এররগুলোতে স্বয়ংক্রিয়ভাবে পুনরায় চেষ্টা করে, এবং আপনি সেটা কেবল ডুপ্লিকেট রো দেখলে টের পাবেন।\n\n### সার্ভার‑সাইড: রিট্রাই, webhook, এবং ব্যাকগ্রাউন্ড ওয়ার্কার\n\nসার্ভারগুলো ইচ্ছাকৃতভাবে কাজ পুনরায় করে। জব কিউগুলো ফেইল হওয়া জবগুলো রিট্রাই করে। webhook প্রদানকারীরা একই ইভেন্ট একাধিকবার ডেলিভার করে, বিশেষ করে যদি আপনার endpoint ধীর বা non-2xx স্টেটাস রিটার্ন করে। যদি আপনার create লজিক এসব ইভেন্ট দ্বারা ট্রিগার হয়, ধরে নিন ডুপ্লিকেট ঘটবেই।\n\n### কনকারেন্সি: দুইটি রিকোয়েস্ট রেসে জিতছে\n\nকনকারেন্সি সবচেয়ে ধূর্ত ডুপ্লিকেট তৈরি করে। দুইটি ট্যাব একই ফর্ম মিলিসেকেন্ডের মধ্যে সাবমিট করতে পারে। যদি সার্ভার "আছে কি না দেখে" তারপর ইনসার্ট করে, দুইটি রিকোয়েস্টই চেক পাস করে ফেলতে পারে আগে কোনো ইনসার্ট হয়।\n\nক্লায়েন্ট, নেটওয়ার্ক, এবং সার্ভারকে আলাদা উৎস হিসেবে বিবেচনা করুন। আপনাকে তিনটাতেই প্রতিরোধ স্থাপন করতে হবে।\n\n## ডাটাবেস ইউনিক কনস্ট্রেইন্ট দিয়ে শুরু করুন (চূড়ান্ত প্রতিরোধ)

\nযদি আপনি ডুপ্লিকেট বন্ধ করার জন্য একটি নির্ভরযোগ্য জায়গা চান, নিয়মটি ডাটাবেসে রাখুন। UI ফিক্স এবং সার্ভার চেক সাহায্য করে, কিন্তু রিট্রাই, ল্যাগ, বা একসাথে দুইজন ব্যবহারকারীর কাণ্ডে তারা ব্যর্থ হতে পারে। একটি ডাটাবেস ইউনিক কনস্ট্রেইন্ট হল চূড়ান্ত কর্তৃপক্ষ।\n\nপ্রথমে এমন একটি বাস্তব-বিশ্ব ইউনিকনেস রুল বেছে নিন যা মানুষ কিভাবে রেকর্ডটি দেখে সেই সাথেই মেলে। সাধারণ উদাহরণগুলো:\n\n- একজন ব্যবহারকারীর জন্য ইমেল ঠিকানা\n- একটি ক্রয়ের জন্য অর্ডার নম্বর\n- একটি পেমেন্ট প্রদানকারীর external_id\n\nআবশ্যক নয় এমন ফিল্ডগুলো নিয়ে সতর্ক থাকুন, যেমন পুরো নাম।\n\nরুল ঠিক হলে, একটি unique constraint (বা unique index) দিয়ে এটি এনফোর্স করুন। এতে ডাটাবেস একই মুহূর্তে আসা দুইটি ইনসার্টকেও প্রত্যাখ্যান করবে যদি সেটা রুল ভঙ্গ করে।\n\nকনস্ট্রেইন্ট ট্রিগার হলে ব্যবহারকারীর অভিজ্ঞতা কী হবে সেটা ঠিক করুন। যদি ডুপ্লিকেট তৈরি করা সবসময় ভুল হয়, তাহলে একটি পরিষ্কার বার্তা দেখান ("এই ইমেলটি ইতিমধ্যে ব্যবহৃত হয়েছে")। যদি রিট্রাই সাধারণ হয় এবং রেকর্ড আগেই আছে, তবে প্রায়ই রিট্রাইকে সফল ধরা এবং বিদ্যমান রেকর্ড ফেরত দেওয়াই ভাল ("আপনার অর্ডার ইতিমধ্যে তৈরি হয়েছে")।\n\n### উপযুক্ত হলে সেফ রাইট প্যাটার্ন ব্যবহার করুন\n\nআপনার create প্রকৃতপক্ষে "create বা reuse" হলে, upsert সবচেয়ে পরিষ্কার প্যাটার্ন হতে পারে। উদাহরণ: "ইমেলের মাধ্যমে কাস্টমার তৈরি" একটি নতুন রো ইনসার্ট করতে পারে বা বিদ্যমানটি ফিরিয়ে দিতে পারে। এটা কেবল তখনই ব্যবহার করুন যখন এটি ব্যবসায়িক মানেই মিলে। যদি একই কী-র জন্য মাঝে মাঝে ভিন্ন পেইলোড আসে, তখন সিদ্ধান্ত নিন কোন ফিল্ডগুলো আপডেট করা যাবে এবং কোনগুলো অপরিবর্তিত থাকবে।\n\nইউনিক কনস্ট্রেইন্ট idempotency কী বা ভালো UI স্টেটকে বদলায় না, কিন্তু এগুলোকে নির্ভর করতে দেওয়ার মতো একটি কঠিন বন্ধনী দেয়।\n\n## Idempotency কী: পুনরাবৃত্তি-নিরাপদ create করুন\n\nএকটি idempotency কী হল একটি ইউনিক টোকেন যা একটি ব্যবহারকারীর ইচ্ছাকে প্রতিনিধিত্ব করে, যেমন "এই অর্ডারটি একবার তৈরি করুন"। একই রিকোয়েস্ট আবার পাঠালে (ডবল ক্লিক, নেটওয়ার্ক রিট্রাই, মোবাইল রিসিউম), সার্ভার এটিকে একটি রিট্রাই হিসেবে বিবেচনা করে, নতুন create হিসেবে নয়।\n\nএটি এমন একটি অত্যন্ত ব্যবহারিক টুল যা ক্লায়েন্ট প্রথম প্রচেষ্টাটি সফল হয়েছে কি না তা বুঝাতে না পারলে create এন্ডপয়েন্টগুলোকে নিরাপদ করে তোলে।\n\nযে এন্ডপয়েন্টগুলো সবচেয়ে উপকৃত হয় সেগুলো হল যেখানে ডুপ্লিকেট ব্যয়বহুল বা বিভ্রান্তিকর, যেমন অর্ডার, ইনভয়েস, পেমেন্ট, ইনভাইট, সাবস্ক্রিপশন, এবং এমন ফর্ম যা ইমেল বা webhook ট্রিগার করে।\n\nরিট্রাই হলে, সার্ভার প্রথম সফল প্রচেষ্টার মূল রেজাল্ট রিটার্ন করা উচিত, একই তৈরি করা রেকর্ড ID এবং স্ট্যাটাস কোডসহ। এর জন্য একটি ছোট idempotency রেকর্ড সংরক্ষণ করুন যা (user বা account) + endpoint + idempotency কী দ্বারা কীড করা আছে। ফলাফল (রেকর্ড ID, রেসপন্স বডি) এবং একটি "in progress" স্টেট সংরক্ষণ করুন যাতে দুইটি কাছাকাছি অনুরোধ দুটি রো না তৈরি করে।\n\nবাস্তব রিট্রাইলার সময় পর্যন্ত idempotency রেকর্ড রাখুন। সাধারণ বেসলাইন হল 24 ঘন্টা। পেমেন্টের জন্য অনেক দল 48–72 ঘন্টা রাখে। একটি TTL স্টোরেজ সীমিত রাখে এবং কতদিন রিট্রাই সম্ভব তা মিলে।\n\nযদি আপনি Koder.ai-এর মতো একটি চ্যাট-চালিত বিল্ডার দিয়ে API জেনারেট করেন, তবুও idempotency স্পষ্ট রাখুন: ক্লায়েন্ট-প্রেরিত কী গ্রহণ করুন (হেডার বা ফিল্ড) এবং সার্ভারে "একই কী, একই ফল" এনফোর্স করুন।\n\n## ধাপে ধাপে: একটি create এন্ডপয়েন্টে idempotency যোগ করা\n\nIdempotency একটি create রিকোয়েস্টকে পুনরাবৃত্তির জন্য নিরাপদ করে। যদি ক্লায়েন্ট টাইমআউটের কারণে রিট্রাই করে (বা ব্যবহারকারী দুইবার ক্লিক করে), সার্ভার একই ফলাফল দেয় নতুন রো তৈরি না করে।\n\n### একটি ব্যবহারিক ৫-ধাপ রেসিপি\n\n1. প্রতিটি ব্যবহারকারীর ইচ্ছার জন্য একটি idempotency কী তৈরি করুন (উদাহরণ: যখন তারা “Create invoice” চাপে)। ক্লায়েন্টেই কী জেনারেট করুন এবং ঐ একচেটিয়া ক্রিয়ার জন্য এটি স্থিতিশীল রাখুন।\n2. সেই কীটি প্রতিবার রিকোয়েস্টের সঙ্গে পাঠান যখনই আপনি সেই create চেষ্টা করেন। একটি হেডার ভালো কাজ করে (যেমন ), কিন্তু JSON বডিতেও পাঠানো যায়।\n3. সার্ভারে, কীকে একটি স্পষ্ট স্কোপের সাথে সংরক্ষণ করুন: কে কল করছে (user বা account), কোন এন্ডপয়েন্টে প্রযোজ্য, এবং কোন create-কে প্রতিনিধিত্ব করছে। ফাইনাল রেসপন্স পে-লোডও সংরক্ষণ করুন।\n4. যদি একই কী একই স্কোপের জন্য আবার আসে, কিছুই তৈরি না করে সংরক্ষিত রেসপন্স (মূল রেকর্ড id সহ) ফিরিয়ে দিন।\n5. দ্রুত ক্লিক, ক্লায়েন্ট রিট্রাই, এবং নেটওয়ার্ক টাইমআউট নকল করে স্ট্রেস টেস্ট করুন। নিশ্চিত করুন ঠিক একটিই নতুন রেকর্ড হচ্ছে।\n\n### সার্ভার লজিক কেমন দেখায়\n\nকী বিষয়টি হলো—“চেক + স্টোর” concurrency-র অধীনে নিরাপদ হতে হবে। বাস্তবে, আপনি idempotency রেকর্ডকে উপর ইউনিক কনস্ট্রেইন্ট দিয়ে সংরক্ষণ করবেন এবং কনফ্লিক্টকে পুনরায় ব্যবহার করার সিগন্যাল হিসাবে বर्तবি করবেন।\n\n```text if idempotency_record exists for (user_id, key): return saved_response else: begin transaction create the row save response under (user_id, key) commit return response