জানুন কিভাবে ACID গ্যারান্টি ডাটাবেস ডিজাইন ও অ্যাপ আচরণকে প্রভাবিত করে। অ্যাটমিকিটি, কনসিস্টেন্সি, আইসোলেশন, ডিউরেবিলিটি, ট্রেড‑অফ এবং বাস্তব উদাহরণগুলো অন্বেষণ করুন।
আপনি যখন মুদি কেনেন, বিমান বুক করেন, বা একাউন্ট থেকে অন্য একাউন্টে টাকা পাঠান, আপনি চান ফলাফল স্পষ্ট হোক: অথবা সফল হয়েছে, অথবা হয়নি। ডাটাবেসগুলোও একই ধরণের নিশ্চয়তা দেওয়ার চেষ্টা করে—যখন অনেকেই সিস্টেম ব্যবহার করছে, সার্ভার ক্র্যাশ করছে, বা নেটওয়ার্কে সমস্যা হচ্ছে।
একটি ট্রানজেকশন হল ডাটাবেস যে একক কাজটিকে একটি "প্যাকেজ" হিসেবে দেখে। এতে একাধিক ধাপ থাকতে পারে—ইনভেন্টরি কমানো, অর্ডার রেকর্ড তৈরি, কার্ড চার্জ করা, রিসিট লেখা—কিন্তু এটি একটিই সঙ্গতিপূর্ণ ক্রিয়ার মতো আচরণ করা উচিত।
যদি কোনো ধাপ ব্যর্থ হয়, সিস্টেমটি অর্ধেক-মোটিভ কাজ রেখে দেয়ার বদলে নিরাপদ বিন্দুতে ঘোরে আসা উচিত।
আংশিক আপডেট শুধু টেকনিক্যাল গোলযোগ নয়; এগুলো কাস্টমার সাপোর্ট টিকিট ও আর্থিক ঝুঁকি হয়ে দাঁড়ায়। উদাহরণস্বরূপ:
এই ধরনের ব্যর্থতা ডিবাগ করা কঠিন কারণ সবকিছু "প্রায় ঠিক" দেখা যায়, তবু সংখ্যাগুলো মিলেনা।
ACID চারটি গ্যারান্টির সংক্ষিপ্ত রূপ যা অনেক ডাটাবেস ট্রানজেকশনের জন্য দিতে পারে:
এটা কোনো নির্দিষ্ট ডাটাবেস ব্র্যান্ড বা একক টগল নয়; এটা আচরণ সম্পর্কে একটি প্রতিশ্রুতি।
শক্তিশালী গ্যারান্টিগুলো সাধারণত ডাটাবেসকে আরও কাজ করাতে বাধ্য করে: অতিরিক্ত সমন্বয়, লকার জন্য অপেক্ষা, ভার্সন ট্র্যাকিং, এবং লগে লেখা। উচ্চ লোডে তা থ্রুপুট কমাতে বা লেটেন্সি বাড়াতে পারে। লক্ষ্য সবসময় “সবসময় সর্বোচ্চ ACID” নয়, বরং এমন গ্যারান্টি বেছে নেওয়া যা আপনার বাস্তব ব্যবসায়িক ঝুঁকির সাথে খাপ খায়।
অ্যাটমিকিটি মানে একটি ট্রানজেকশনকে একক কাজ হিসেবে দেখা: এটি অথবা পুরোপুরি শেষ হবে, অথবা কোনো প্রভাবই থাকবে না। আপনি কখনোই ডাটাবেসে "অর্ধেক আপডেট" দেখতে পাবেন না।
ধরা যাক আলিস থেকে বব-এ $50 পাঠানো হচ্ছে। অন্তত দুটি পরিবর্তন থাকে:
অ্যাটমিকিটির সাথে, ওই দুটি পরিবর্তন একসাথে সফল হবে বা একসাথে ব্যর্থ হবে। সিস্টেম যদি উভয় নিরাপদে করতে না পারে, তবে কিছুই করা উচিত নয়। এতে আলিস চার্জ হয়েছে কিন্তু বব পায়নি—এরকম ভয়াবহ অবস্থা প্রতিরোধ হয়।
ডাটাবেস ট্রানজেকশনের জন্য দুইটি পথ দেয়:
একটি মেন্টাল মডেল হিসেবে ভাবুন: "ড্রাফট বনাম প্রকাশ"। ট্রানজেকশন চলাকালীন পরিবর্তনগুলো প্রস্তাবিত; কেবল commit সেগুলো প্রকাশ করে।
অ্যাটমিকিটি গুরুত্বপূর্ণ কারণ ব্যর্থতা স্বাভাবিক:
এইগুলো যদি commit পূর্ণ হওয়ার আগে ঘটেঃ অ্যাটমিকিটি নিশ্চিত করে ডাটাবেস রোলব্যাক করতে পারে যাতে আংশিক কাজ স্থায়ী রাষ্ট্রে লিক না করে।
অ্যাটমিকিটি ডাটাবেস স্টেটকে রক্ষা করে, কিন্তু আপনার অ্যাপ্লিকেশনকে অনিশ্চয়তা সামলাতে হবে—বিশেষত যখন নেটওয়ার্ক ড্রপের ফলে জানতে পারছেন না commit হয়েছে কি না।
দুইটি বাস্তবিক পরিপূরক:
অ্যাটমিক ট্রানজেকশন এবং idempotent retries একসাথে আংশিক আপডেট ও দৈবিক ডাবল-চার্জ উভয়ই এড়াতে সহায়ক।
ACID-এ কনসিস্টেন্সি মানে হলো "ডাটাবেস প্রতিটি ট্রানজেকশনের মাধ্যমে আপনার নির্ধারিত নিয়ম অনুযায়ী একটি বৈধ অবস্থาจান্না থেকে আরেকটি বৈধ অবস্থায় যাবে"—এটি ডেটা ‘যুক্তিসংগত দেখায়’ বা সব রেপ্লিকা মিলে থাকে এমনটা বোঝায় না।
একটি ডাটাবেস কেবল সেই নিয়মগুলোর পরিপ্রেক্ষিতে কনসিস্টেন্ট থাকতে পারে যেগুলো আপনি স্পষ্টভাবে সেট করেন—কনস্ট্রেইন্ট, ট্রিগার, এবং ইনভারিয়েন্ট। ACID নিজে এসব নিয়ম আবিষ্কার করে না; এটি ট্রানজেকশনের সময় এগুলো কার্যকর করে।
সাধারণ উদাহরণ:
order.customer_id অবশ্যই একটি বিদ্যমান কাস্টমার নির্দেশ করবে।এই নিয়ম থাকলে ডাটাবেস এমন কোনো ট্রানজেকশন প্রত্যাখ্যান করবে যা এগুলো ভাঙে—তাতে আপনার কাছে "আধা-বৈধ" ডেটা থাকবে না।
অ্যাপ-স্তরের ভ্যালিডেশন গুরুত্বপূর্ণ, কিন্তু একা এটা যথেষ্ট নয়।
ক্লাসিক ব্যর্থতা: অ্যাপ-এ চেক করা ("ইমেইল খালি আছে") তারপর ইনসার্ট করা। কনকারেন্সির মধ্যে দুইটি অনুরোধ একই সময়ে চেক পাস করতে পারে। ডাটাবেসে থাকা unique constraint একমাত্র গ্যারান্টি যে মাত্র একটিই ইনসার্ট সফল হবে।
আপনি যদি "নেগেটিভ ব্যালান্স নেই" নিয়মটি কনস্ট্রেইন্ট হিসেবে এনকোড করেন (বা একক ট্রানজেকশনের ভিতরে নির্ভরযোগ্যভাবে তা প্রয়োগ করেন), তাহলে যেকোনো ট্রান্সফার যা অ্যাকাউন্ট ওভারড্র করত সেটি পুরোপুরি ব্যর্থ হবে। যদি আপনি ওই নিয়ম কোথাও এনকোড না করেন, ACID এটি রক্ষা করতে পারবে না—কারণ প্রয়োগ করার মতো কিছুই নেই।
কনসিস্টেন্সি মূলত স্পষ্ট হওয়ার বিষয়ে: নিয়মগুলো নির্ধারণ করুন, তারপর ট্রানজেকশনগুলো নিশ্চিত করুক যে সেগুলো কখনো ভাঙে না।
আইসোলেশন নিশ্চিত করে ট্রানজেকশনগুলো একে অপরের উপর চাপ না ফেলে। যখন এক ট্রানজেকশন চলছে, অন্যরা অর্ধেক-সম্পন্ন কাজ না দেখে বা আকস্মিকভাবে ওভাররাইট না করেই থাকা উচিত। লক্ষ্য হলো: প্রতিটি ট্রানজেকশন যেন একা চালনার মত আচরণ করে, যদিও অনেক ব্যবহারকারী একসাথে সক্রিয়।
বাস্তব সিস্টেম ব্যস্ত: কাস্টমার অর্ডার দেয়, সাপোর্ট এজেন্ট প্রোফাইল আপডেট করে, ব্যাকগ্রাউন্ড জব পেমেন্ট রিকনসাইল করে—সবই একসাথে। এই ক্রিয়াগুলো সময়ে ও স্পর্শকাতর রো উভয়ই ওভারল্যাপ করে।
আইসোলেশন না থাকলে টাইমিং আপনার ব্যবসায়িক লজিকের অংশ হয়ে যায়। "স্টক বিয়োগ" আপডেট অন্য চেকআউটের সাথে রেস করতে পারে, বা একটি রিপোর্ট মাঝখানে ডেটা পড়ে এমন সংখ্যা দেখাতে পারে যা কখনোই স্থিতিশীল অবস্থায় উপস্থিত ছিল না।
সম্পূর্ণ "তুমি একা চালাও" আইসোলেশন ব্যয়বহুল হতে পারে। এটি থ্রুপুট কমাতে, অপেক্ষা (লক) বাড়াতে, বা ট্রানজেকশনের রিট্রাই বাড়াতে পারে। অনেক ওয়ার্কফ্লো সবচেয়ে কঠোর সুরক্ষা প্রয়োজন করে না—উদাহরণ: গতকালের অ্যানালিটিক্স পড়া সামান্য অসঙ্গতি সহ্য করতে পারে।
এস কারণেই ডাটাবেসগুলো কনফিগারযোগ্য আইসোলেশন লেভেল দেয়: আপনি ঠিক করেন কতটা কনকারেন্সি ঝুঁকি মেনে নেবেন ভাল পারফরম্যান্স ও কম কনফ্লিক্ট পেতে।
যখন আইসোলেশন আপনার কাজের জন্য খুব দুর্বল, তখন ক্লাসিক অ্যানোমালিগুলো দেখা যাবে:
এই ব্যর্থ মোডগুলো বোঝা সহজ করে দেয় কোন আইসোলেশন লেভেল আপনার প্রোডাক্টের প্রমিসের সাথে মানানসই।
আইসোলেশন নির্ধারণ করে আপনার ট্রানজেকশন চলাকালীন আপনি অন্যদের কি দেখতে পারবেন। দুর্বল আইসোলেশন থাকলে আপনি অপ্রত্যাশিত আচরণ পেতে পারেন:
Dirty read ঘটে যখন আপনি এমন ডেটা পড়েন যা অন্য ট্রানজেকশন লিখেছে কিন্তু কমিট করেনি।
দৃশ্য: অ্যালেক্স $500 ট্রান্সফার করে, ব্যালান্স সাময়িকভাবে $200 হয়, এবং আপনি সেই $200 পড়ে ফেলেন; পরে অ্যালেক্সের ট্রানজেকশন ব্যর্থ হয়ে রোলব্যাক করলে আপনি ভুল ব্যালান্স দেখেছেন।
ব্যবহারকারীর ফলাফল: গ্রাহক ভুল লো ব্যালান্স দেখে, ফ্রড রুল ভুল ট্রিগার করে, বা সাপোর্ট এজেন্ট ভুল তথ্য দেয়।
Non-repeatable read মানে একই রো দুবার পড়লে ভিন্ন মান পেতে পারেন কারণ অন্য ট্রানজেকশন মাঝখানে কমিট করেছে।
দৃশ্য: আপনি একটি অর্ডার টোটাল ($49.00) লোড করেন, পরে রিফ্রেশ করলে দেখতে পান $54.00 কারণ কোনো ডিসকাউন্ট লাইন মুছে গেছে।
ব্যবহারকারীর ফলাফল: “আমার মোট চেকআউটের সময় বদলে গেছে”—বিশ্বাসহীনতা বা চেকআউট ত্যাগ।
Phantom read হল non-repeatable read-এর মত, কিন্তু সেট লেভেলে: একই কুয়েরি আবার চালালে নতুন বা অনুপস্থিত সারি দেখা যায় কারণ অন্য ট্রানজেকশন মিল খোঁজেন এমন রেকর্ড ইনসার্ট/ডিলিট করেছে।
দৃশ্য: হোটেল সার্চে দেখা যায় “3 রুম পাওয়া যাচ্ছে”, পরে বুক করার সময় পুনর্চেক করলে কোনো রুম নেই কারণ নতুন রিজার্ভেশন যুক্ত হয়েছে।
ব্যবহারকারীর ফলাফল: ডাবল বুকের চেষ্টা, অসম্ভব অ্যাভেলিবিলিটি স্ক্রিন, বা ওভারসেলিং।
Lost update ঘটে যখন দুই ট্রানজেকশন একই মান পড়ে এবং দুজনই আপডেট করে, পরে শেষটি আগে উধাও করে দেয়।
দৃশ্য: দুই অ্যাডমিন একই প্রোডাক্ট প্রাইস এডিট করে। দুজনই $10 থেকেই শুরু করে; একজন $12 সেভ করে, আরেকজন পরে $11 সেভ করে—কারো পরিবর্তন হারিয়ে যায়।
ব্যবহারকারীর ফলাফল: কারোর পরিবর্তন অদৃশ্য; রিপোর্ট/টোটাল ভুল হয়ে যায়।
Write skew ঘটে যখন দুই ট্রানজেকশন প্রতিটি করে এমন পরিবর্তন করে যা একাধিকভাবে যাচাই করলে বৈধ, কিন্তু একসাথে মিলিয়ে এক নিয়ম ভঙ্গে।
দৃশ্য: নিয়ম: “কমপক্ষে একজন অন-কল ডাক্তার থাকা উচিত।” দুই ডাক্তার আলাদাভাবে চেক করে যে অন্যজন অন-কল আছে এবং উভয়েই অফ-কল চিহ্ন করে।
ব্যবহারকারীর ফলাফল: আপনি শূন্য কভারেজের সঙ্গে শেষ করেন, যদিও প্রতিটি ট্রানজেকশনই চেক পাস করেছিল।
কঠোর আইসোলেশন অ্যানোমালি কমায় কিন্তু অপেক্ষা, রিট্রাই, এবং খরচ বাড়ায় উচ্চ কনকারেন্সির সময়। অনেক সিস্টেম পড়াই-ভিত্তিক অ্যানালিটিক্সের জন্য দুর্বল আইসোলেশন বেছে নেয়, যখন মানি মুভমেন্ট, বুকিং মতো correctness-critical ফ্লো কঠোর সেটিংস ব্যবহার করে।
আইসোলেশন নির্ধারণ করে আপনার ট্রানজেকশন অন্যরা চলাকালীন কী দেখতে পারবে। ডাটাবেস এটাকে আইসোলেশন লেভেল হিসেবে প্রকাশ করে: উচ্চ লেভেল অপ্রত্যাশিত আচরণ কমায়, কিন্তু খরচ বাড়ায়।
টিমগুলো প্রায়ই Read Committed কে ডিফল্ট হিসেবে নেয় কারণ এটি ভাল পারফরম্যান্স দেয় এবং "dirty reads নেই" বেশিরভাগ প্রত্যাশার সাথে মেলে।
যদি আপনাকে ট্রানজেকশনের ভিতরে স্থির ফলাফল দরকার (উদাহরণ: লাইন আইটেম থেকে ইনভয়েস তৈরি), Repeatable Read নিন এবং আপনি কিছু ওভারহেড মেনে নিতে পারবেন।
যদি correctness কনকারেন্সির চেয়ে বেশি গুরুত্বপূর্ণ (উদাহরণ: ওভারসেলিং প্রতিরোধ), Serializable ব্যবহার করুন—তবে কনটেনশন/রিট্রাই বাড়বে।
Read Uncommitted OLTP সিস্টেমে বিরল; এটা কখনো কখনো মনিটরিং বা আনুমানিক রিপোর্টিংয়ে ব্যবহার করা হয় যেখানে মাঝে মাঝে ভুল পড়া গ্রহণযোগ্য।
নামগুলো স্ট্যান্ডার্ড হলেও ঠিক কী গ্যারান্টি দেয় সেটা DB ইঞ্জিন অনুযায়ী ভিন্ন হতে পারে (এবং কনফিগারেশনেও পরিবর্তিত হতে পারে)। আপনার ডাটাবেস ডকুমেন্টেশন যাচাই করুন এবং যে অ্যানোমালিগুলো আপনার ব্যবসার জন্য গুরুত্বপূর্ণ সেগুলো টেস্ট করে দেখুন।
ডিউরেবিলিটি মানে হল একবার ট্রানজেকশন commit হয়ে গেলে তার ফলাফল ক্র্যাশের পরও টিকে থাকবে—পাওয়ার লস, প্রক্রিয়া পুনরায় চালু বা হঠাৎ মেশিন রিবুট। যদি আপনার অ্যাপ গ্রাহককে বলে "পেমেন্ট সফল হয়েছে", ডিউরেবিলিটি সেটা ভুলে যাবে না—এই প্রতিশ্রুতি দেয়।
অধিকাংশ রিলেশনাল ডাটাবেস write-ahead logging (WAL) দিয়ে ডিউরেবিলিটি অর্জন করে। উচ্চ স্তরে, ডাটাবেস commit গণ্য করার আগে পরিবর্তনগুলোর সিরিয়াল "রিসিপ্ট" লগ-এ ডিস্কে লেখে। যদি ডাটাবেস ক্র্যাশ করে, স্টার্টআপে লগ রিরেপ্লে করে কমিট হওয়া পরিবর্তনগুলো পুনরুদ্ধার করা যায়।
রিকভারি সময় যুক্তিযুক্ত রাখতে ডাটাবেস চেকপয়েন্টও তৈরি করে: একটি চেকপয়েন্টে ডাটাবেস নিশ্চিত করে যে সাম্প্রতিক পরিবর্তনের যথেষ্ট অংশ প্রধান ডেটা ফাইলগুলোতে লেখা আছে, ফলে রিকভারি অপ্রতিবদ্ধ লগ ইতিহাস রিরেপ্লে করতে হবে না।
ডিউরেবিলিটি একক অন/অফ সুইচ নয়; এটি কিভাবে ডাটাবেস ডাটা স্থায়ী স্টোরেজে জোর করে লেখে তার ওপর নির্ভর করে।
fsync), যা নিরাপদ কিন্তু লেটেন্সি বাড়ায়।আন্ডারলাইনিং হার্ডওয়্যারও গুরুত্বপূর্ণ: SSD, RAID কন্ট্রোলার উইথ রাইট কেশ, এবং ক্লাউড ভলিউমগুলো ব্যর্থতার সময় ভিন্ন আচরণ করতে পারে।
ব্যাকআপ ও রেপ্লিকেশন আপনাকে রিকভার করতে বা ডাউনটাইম কমাতে সাহায্য করে, কিন্তু সেগুলো ডিউরেবিলিটির সমপর্যায় গ্যারান্টি নয়। একটি ট্রানজেকশন প্রাইমারিতে ডিউরেবল থাকতে পারে যদিও তা রেপ্লিকায় পৌঁছায়নি, এবং ব্যাকআপগুলি সাধারণত পয়েন্ট-ইন-টাইম স্ন্যাপশট—কমিট-বাই-কমিট গ্যারান্টি নয়।
যখন আপনি BEGIN করে পরে COMMIT করেন, ডাটাবেস অনেকগুলো চলমান অংশকে সমন্বয় করে: কারা কোন রো পড়তে পারে, কারা আপডেট করতে পারে, এবং যখন দুইজন একই রেকর্ড বদলাতে চায় তখন কী হয়।
একটি বড় “আন্ডার-দ্য-হুড” পছন্দ হল কনফ্লিক্ট কীভাবে হ্যান্ডেল করা হবে:
অনেক সিস্টেম লোড ও আইসোলেশন লেভেলের উপর ভিত্তি করে উভয় ধারণার মিশ্রণ ব্যবহার করে।
আধুনিক ডাটাবেস প্রায়ই MVCC (Multi-Version Concurrency Control) ব্যবহার করে: একটি রো-এর একক কপি রাখার বদলে ডাটাবেস একাধিক ভার্সন রাখে।
এই কারণেই কিছু ডাটাবেস অনেক রিড ও রাইট একসাথে অনায়াসে হ্যান্ডেল করতে পারে—তবু রাইট/রাইট কনফ্লিক্টগুলো সমাধান করা দরকার।
লকগুলো deadlock সৃষ্টি করতে পারে: ট্রানজেকশন A B-র ধরে থাকা লকের জন্য অপেক্ষা করে, আর B A-র ধরে থাকা লকের জন্য অপেক্ষা করে।
ডাটাবেস সাধারণত চক্র সনাক্ত করে এবং একটিকে abort করে (deadlock victim), যাতে অ্যাপ্লিকেশন রিট্রাই করতে পারে।
যদি ACID প্রয়োগ ঘর্ষণ তৈরি করে, সাধারণত আপনি দেখতে পাবেন:
এই লক্ষণগুলো সাধারণত বলে দেয় ট্রানজেকশনের আকার, ইনডেক্সিং, বা আইসোলেশন/লকিং স্ট্র্যাটেজি পুনর্বিবেচনার সময়।
ACID গ্যারান্টি শুধু তত্ত্ব নয়—এগুলো আপনার API, ব্যাকগ্রাউন্ড জব, এমনকি UI ফ্লো ডিজাইনকেও প্রভাবিত করে। মূল ধারণা: কোন ধাপগুলো একসাথে সফল হতে হবে তা নির্ধারণ করুন, তারপর কেবল ঐ ধাপগুলোই একটি ট্রানজেকশনে রাখুন।
একটি ভাল ট্রানজেকশনাল API সাধারণত একটি একক ব্যবসায়িক ক্রিয়াকে ম্যাপ করে, যদিও তা বহু টেবিলে স্পর্শ করে। উদাহরণ: /checkout অপারেশনটি হতে পারে: অর্ডার তৈরি, ইনভেন্টরি রিজার্ভ, ও পেমেন্ট ইন্টেন্ট রেকর্ড। ঐ ডাটাবেস লেখাগুলো সাধারণত এক ট্রানজেকশনে থাকা উচিত যাতে সেগুলো একসাথে commit (বা একসাথে roll back) হয় যদি কোনো ভ্যালিডেশন ব্যর্থ হয়।
একটি সাধারণ প্যাটার্ন:
এতে অ্যাটমিকিটি ও কনসিস্টেন্সি বজায় রাখা যায় এবং ধীর, ভঙ্গুর ট্রানজেকশন এড়ানো যায়।
ট্রানজেকশন বাউন্ডারি কোথায় রাখবেন তা নির্ভর করে "একটি কাজ" কী বোঝায়:
ACID সাহায্য করলেও অ্যাপ্লিকেশনকে এখনও ব্যর্থতা সঠিকভাবে হ্যান্ডেল করতে হয়:
বর্জন করুন: দীর্ঘ ট্রানজেকশন, ট্রানজেকশনের ভিতরে বাইরের API কল, এবং ট্রানজেকশনে ব্যবহারকারী থিঙ্ক টাইম (উদাহরণ: "কার্ট রো লক কর, ব্যবহারকারী কনফার্ম করুন")। এগুলো কনটেনশন বাড়ায় ও আইসোলেশন কনফ্লিক্টকে বাড়ায়।
যদি আপনি দ্রুত ট্রানজেকশনাল সিস্টেম বানাচ্ছেন, সবচেয়ে বড় ঝুঁকি সাধারণত "ACID না জানা" নয়—এটি এক ব্যবসায়িক কাজকে ভুলভাবে বহু এন্ডপয়েন্ট, জব, বা টেবিলে ছড়িয়ে দেওয়া।
প্ল্যাটফর্ম যেমন Koder.ai আপনাকে দ্রুত বানাতে সাহায্য করতে পারে: আপনি একটি ওয়ার্কফ্লো (উদাহরণ: "চেকআউট ইনভেন্টরি রিজার্ভ ও পেমেন্ট ইন্টেন্ট") পরিকল্পনা-প্রথম চ্যাটে বর্ণনা করলে, একটি React UI এবং Go + PostgreSQL ব্যাকেন্ড জেনারেট করতে পারবেন, এবং স্কিমা বা ট্রানজেকশন বাউন্ডারি বদলাতে স্ন্যাপশট/রোলব্যাক করে এগোতে পারবেন। ডাটাবেস গ্যারান্টি অক্ষুন্ন থাকে; মূল্য হলো সঠিক ডিজাইন থেকে কাজ করা দ্রুততর করা।
একক ডাটাবেস সাধারণত একটি ট্রানজেকশনের সীমার মধ্যে ACID গ্যারান্টি দিতে পারে। যখন কাজ বহু সার্ভিস (এবং প্রায়ই বহু ডাটাবেস) জুড়ে ছড়ায়, তখন একই গ্যারান্টি বজায় রাখা কঠিন হয়ে যায়—এবং যখন আপনি তা বজায় রাখতে চান, ব্যয় বেড়ে যায়।
কঠোর কনসিস্টেন্সি মানে প্রতিটি রিড সর্বশেষ কমিটেড সত্য দেখায়। উচ্চ অ্যাভেইলেবিলিটি মানে সিস্টেম উত্তর দেয় এমনকি যখন কিছু অংশ ধীর বা অনুপলব্ধ। মাল্টি-সার্ভিস সেটআপে অস্থায়ী নেটওয়ার্ক সমস্যা আপনাকে একটি পছন্দে বাধ্য করতে পারে: সব অংশ সম্মত না হওয়া পর্যন্ত অনুরোধ ব্লক বা ব্যর্থ করা (বেশি কনসিস্টেন্ট, কম অ্যাভেইলেবল), বা সাময়িকভাবে সেবা একে অপরের থেকে আলাদা থাকতে দেওয়া (বেশি অ্যাভেইলেবল, কম কনসিস্টেন্ট)। কোনোটাই সবসময় সঠিক নয়—এটি নির্ভর করে আপনার ব্যবসা কোন ভুল সহ্য করতে পারে।
বিতরণকৃত ট্রানজেকশনগুলো এমন সীমা-লঙ্ঘন করে যা আপনি পুরোপুরি নিয়ন্ত্রণ করেন না: নেটওয়ার্ক বিলম্ব, রিট্রাই, টাইমআউট, সার্ভিস ক্র্যাশ, আংশিক ব্যর্থতা।
প্রত্যেক সার্ভিস সঠিক থাকলেও নেটওয়ার্ক অনির্ণায়কতা তৈরি করতে পারে: পেমেন্ট সার্ভিস কমিট করেছে কিন্তু অর্ডার সার্ভিসের কাছে ACK পৌঁছায়নি। এটিকে নিরাপদে সমাধান করতে সমন্বয় প্রোটোকল (যেমন two-phase commit) ব্যবহার করা হয়, যা ধীর হতে পারে, ব্যর্থতার সময় উপলভ্যতা কমায়, এবং অপারেশনাল জটিলতা বাড়ায়।
Sagas ওয়ার্কফ্লোকে ধাপে ভাগ করে, প্রত্যেক ধাপ লোকালি কমিট হয়। যদি পরে কোনো ধাপ ব্যর্থ হয়, আগের ধাপগুলোকে "compensating actions" (যেমন রিফান্ড) দিয়ে উল্টানো হয়।
Outbox/inbox প্যাটার্ন ইভেন্ট পাবলিশিং ও কনজাম্পশনের নির্ভরযোগ্য করে। একটি সার্ভিস ব্যবসায়িক ডেটা এবং "প্রকাশ করার ইভেন্ট" একই লোকাল ট্রানজেকশনে (outbox) লেখে। কনজিউমাররা প্রক্রিয়ায় থাকা মেসেজ ID (inbox) রেকর্ড করে যাতে রিট্রাই-এর সময় ডুপ্লিকেশন না ঘটে।
Eventual consistency স্বীকার করে যে সেবাগুলোর মধ্যে সামান্য সময়ের জন্য ডেটা আলাদা থাকতে পারে, এবং সমন্বয়ের একটি পরিষ্কার পরিকল্পনা থাকে।
আপনি গ্যারান্টি শিথিল করবেন যখন:
ঝুঁকি নিয়ন্ত্রণ করুন ইনভারিয়েন্টস নির্ধারণ করে (কি কখনোই ভাঙবে না), অপারেশনগুলো idempotent করে, টাইমআউট ও ব্যাকঅফ সহ রিট্রাই নীতি ব্যবহার করে, এবং ড্রিফ্ট মনিটর করে (স্টাকড সাগাস, বারবার ক্ষতিপূরণ, বাড়তে থাকা আউটবক্স টেবিল)। সত্যিই গুরুত্বপূর্ণ ইনভারিয়েন্টস (উদাহরণ: "কখনোই অ্যাকাউন্ট ওভারস্পেন্ড না করা") রাখুন এক জন সার্ভিস ও এক ডাটাবেস ট্রানজেকশনের ভেতরে যেখানে সম্ভব।
একটি ট্রানজেকশন ইউনিট টেস্টে "কোরেক্ট" হতে পারে, তবু রিয়েল ট্রাফিক, রিস্টার্ট, ও কনকারেন্সির অধীনে ব্যর্থ হতে পারে। এই চেকলিস্ট ব্যবহার করুন যাতে ACID গ্যারান্টি প্রোডাকশনের আচরণের সাথে সঙ্গত থাকে।
শুরু করুন কী সবসময় সত্য হতে হবে তা লিখে (আপনার ডেটা ইনভারিয়েন্টস)। উদাহরণ: “অ্যাকাউন্ট ব্যালান্স কখনো নেতিবাচক হবে না”, “অর্ডার টোটাল লাইন আইটেমের যোগফল সমান”, “ইনভেন্টরি কখনো শূন্যর নিচে যাবে না”, “একটি পেমেন্ট ঠিক এক অর্ডারের সাথে লিঙ্কড”। এগুলোকে প্রোডাক্ট নিয়ম হিসেবে বিবেচনা করুন, ডাটাবেস ট্রিভিয়া হিসেবে নয়।
তারপর সিদ্ধান্ত নিন কি অবশ্যই এক ট্রানজেকশনের ভিতরে থাকতে হবে এবং কি পিছনে ফেলা যেতে পারে।
ট্রানজেকশনগুলো ছোট রাখুন: কম রো টাচ করুন, কম কাজ করুন (কোনো বাইরের API কল নয়), এবং দ্রুত commit করুন।
কনকারেন্সিকে একটি প্রথম-শ্রেণীর টেস্ট ডাইমেনশন বানান।
যদি আপনি রিট্রাই সমর্থন করেন, একটি স্পষ্ট idempotency key যোগ করে পরীক্ষা করুন "সাফল্যের পরে অনুরোধ পুনরায় করা" কেস।
যে মেট্রিকগুলো বলবে আপনার গ্যারান্টি খরচশীল বা ভঙ্গুর হচ্ছে সেগুলো দেখুন:
ট্রেন্ড নিয়ে অ্যালার্ট দিন, শুধু স্পাইক না—এবং মেট্রিকগুলোকে সংশ্লিষ্ট এন্ডপয়েন্ট বা জবের সাথে যুক্ত করুন।
আপনার ইনভারিয়েন্টস রক্ষা করার জন্য সবচেয়ে দুর্বল আইসোলেশন ব্যবহার করুন; ডিফল্টভাবে সর্বোচ্চ সেটিং ব্যবহার করবেন না। যেখানে একটি ছোট ক্রিটিক্যাল সেকশন (মানি মুভমেন্ট, ইনভেন্টরি ডিক্রিমেন্ট) কঠোর সঠিকতা চায়, ট্রানজেকশনকে ঠিক ঐ অংশ পর্যন্ত সীমাবদ্ধ রাখুন এবং সবকিছু বাইরে রাখুন।
ACID হলো ট্রানজেকশনাল গ্যারান্টিগুলোর একটি সেট যা ব্যর্থতা ও সমান্তরালতার মুখোমুখি হলে ডাটাবেসকে পূর্বানুমানযোগ্য করে তোলে:
একটি ট্রানজেকশন হল এমন একক “ইউনিট অফ ওয়ার্ক” যা ডাটাবেস একটি প্যাকেজ হিসাবে বিবেচনা করে। সেটা বহু SQL স্টেটমেন্টই হতে পারে (যেমন: অর্ডার তৈরি, স্টক কমানো, পেমেন্ট ইন্টেন্ট রেকর্ড করা), কিন্তু এর ফলাফল দুইরকমই হতে পারে:
আংশিক আপডেটগুলো বাস্তব বিশ্বে বিরোধ সৃষ্টি করে এবং পরে মেরামত করতে ব্যয়বহুল: উদাহরণস্বরূপ:
ACID (বিশেষত atomicity + consistency) এ ধরনের “আধা-সম্পন্ন” অবস্থা ডাটাবেসে সত্য হিসেবে প্রদর্শিত হওয়া থেকে আটকায়।
অ্যাটমিকিটি নিশ্চিত করে যে ডাটাবেস কখনোই “অর্ধেক-সম্পন্ন” ট্রানজেকশন প্রকাশ করবে না। যদি commit হওয়ার পূর্বে কোনো কিছু ব্যর্থ হয়—অ্যাপ ক্র্যাশ, নেটওয়ার্ক ড্রপ, DB রিস্টার্ট—তাহলে ট্রানজেকশন রোলব্যাক করা হবে যাতে আগের ধাপগুলো স্থায়ী অবস্থায় লিক না করে।
প্রায়োগিকভাবে, এটিই বহু-ধাপ পরিবর্তন (যেমন দুইটি ব্যাল্যান্স আপডেট করে একটি ট্রান্সফার) নিরাপদ করে তোলে।
আপনি সব সময় জানতে পারবেন না যে commit হয়েছে কি না যদি ক্লায়েন্ট রেসপন্স হারায় (উদাহরণ: commit হওয়ার ঠিক পর নেটওয়ার্ক টাইমআউট)। এজন্য ACID ট্রানজেকশনের সাথে মিলিয়ে ব্যবহার করুন:
এভাবে partial আপডেট ও অনিচ্ছাকৃত ডাবল-চার্জ উভয়েই এড়ানো যায়।
ACID-এ “consistency” অর্থ হল ডাটাবেস আপনার নির্ধারিত নিয়ম অনুযায়ী একটি বৈধ অবস্থা থেকে আরেকটি বৈধ অবস্থায় যাবে—এটি ডেটা ‘দেখতে যুক্তিপূর্ণ’ হওয়া বা সব রেপ্লিকার মেলে এটি বোঝায় না।
যদি আপনি কোন নিয়ম (উদাহরণ: ব্যালান্স কখনই নেতিবাচক হবে না) কোথাও এনকোড না করেন, ACID সেটি স্বয়ংক্রিয়ভাবে রক্ষা করতে পারবে না। ডাটাবেসকে কাজ করার জন্য স্পষ্ট কনস্ট্রেইন্ট, ট্রিগার ও ইনভারিয়েন্ট লাগবে।
অ্যাপ-স্তরের ভ্যালিডেশন UX উন্নত করে এবং জটিল ব্যবসায়িক নিয়ম প্রয়োগে সহায়ক, কিন্তু কনকারেন্সির অধীনে তা পর্যাপ্ত নয় (উদাহরণ: দুইটি অনুরোধ একই সময়ে ‘ইমেইল ফ্রি’ চেক করলে দুটোই পাশ করে)।
ডাটাবেস কনস্ট্রেইন্ট চূড়ান্ত গেটকিপার হিসেবে কাজ করে:
দুই দিকই ব্যবহার করুন: অ্যাপে আগেভাগে ভ্যালিডেট করুন, ডাটাবেসে চূড়ান্তভাবে বাধ্য করুন।
আইসোলেশন নিয়ন্ত্রণ করে আপনার ট্রানজেকশন অন্যরা চলাকালীন কি দেখতে পায়। দুর্বল আইসোলেশন কিছু অস্বাভাবিকতা (anomalies) সৃষ্টি করতে পারে, যেমন:
আইসোলেশন লেভেলগুলোর মাধ্যমে আপনি পারফরম্যান্স ও সুরক্ষার মধ্যে বেছে নেবেন।
বহু সিস্টেমে ডিফল্ট প্র্যাকটিক্যাল সেটিং হলো Read Committed: এটি dirty reads রোধ করে এবং পারফরম্যান্স ভালো রাখে। যখন দরকার:
সবসময় আপনার DB ইঞ্জিনে নামগুলোর সঠিক আচরণ পরীক্ষা করে দেখুন, কারণ ইঞ্জিন অনুযায়ী ডিটেইল ভিন্ন হতে পারে।
দূরদৃষ্টি দেয় যে একবার একটি ট্রানজেকশন commit হলে তার ফলাফল ক্র্যাশের পরও টিকে থাকবে। সাধারণত এটি write-ahead logging (WAL) ও চেকপয়েন্টের মাধ্যমে বাস্তবায়িত হয়: পরিবর্তনের একটি সিরিয়াল লগ ডিস্কে লিখে রাখা হয় commit গণ্য করার আগে, এবং ক্র্যাশ হলে সেই লগ রিরেপ্লে করে পরিবর্তন পুনরুদ্ধার করা যায়।
তবে এটি কনফিগারেশন-নির্ভর:
ACID বাস্তবায়নে ডাটাবেস বহু অংশ সমন্বয় করে: কে কোন রো পড়তে/লেখতে পারবে, একই রেকর্ডে একাধিকwrites কীভাবে ম্যানেজ হবে ইত্যাদি।
কিছু সাধারণ নীতি:
ব্যাকআপ ও রেপ্লিকেশন recovery ও availability-তে সাহায্য করে, কিন্তু তা নিজে থেকে durability-এর সমপর্যায় গ্যারান্টি নয়।
যদি ACID রক্ষা করে কাজ করলে সমস্যা বাড়ে, লক্ষণগুলো হলো লক-ওয়েট বাড়া, টাইমআউট, ও কনটেনশন হটস্পট—এইগুলো দেখা মানে ট্রানজেকশন আকার, ইনডেক্সিং বা আইসোলেশন স্ট্র্যাটেজি পুনর্বিবেচনার সময়।