২১ সেপ, ২০২৫·6 মিনিট
এরিক ব্রিউয়ারের CAP চিন্তা: কেন বিতরণকৃত সিস্টেম ট্রেডঅফ করে
এরিক ব্রিউয়ারের CAP তত্ত্বকে একটি ব্যবহারিক মানসিক মডেলে শিখুন: কীভাবে সামঞ্জস্য, প্রাপ্যতা এবং পার্টিশন বিতরণকৃত সিস্টেমে সিদ্ধান্তকে আকার দেয়।
এরিক ব্রিউয়ারের CAP তত্ত্বকে একটি ব্যবহারিক মানসিক মডেলে শিখুন: কীভাবে সামঞ্জস্য, প্রাপ্যতা এবং পার্টিশন বিতরণকৃত সিস্টেমে সিদ্ধান্তকে আকার দেয়।
যখন আপনি একই ডেটা একের বেশি মেশিনে সংরক্ষণ করেন, আপনি গতি ও ত্রুটি সহনশীলতা পান—কিন্তু এক নতুন সমস্যা বাড়ে: অমিল। দুইটি সার্ভার ভিন্ন আপডেট পেতে পারে, মেসেজ বিলম্বিত বা হারিয়ে যেতে পারে, এবং ব্যবহারকারীরা যে রেপ্লিকায় কাছে যায় তার উপর ভিত্তি করে ভিন্ন ফলাফল পড়তে পারে। CAP জনপ্রিয় হয়ে ওঠে কারণ এটি ইঞ্জিনিয়ারদের সেই গোলমেলে বাস্তবতাকে হাতাঘোরা ছাড়া পরিষ্কারভাবে আলোচনা করার উপায় দেয়।
এরিক ব্রিউয়ার, একজন কম্পিউটার বিজ্ঞানী এবং Inktomi-এর সহ-প্রতিষ্ঠাতা, ২০০০ সালে প্রতিলিপিযুক্ত সিস্টেমের ব্যর্থতার সময় এই মূল ধারণাটি একটি প্রয়োজনীয় বিবৃতির রূপে উপস্থাপন করেন। এটি দ্রুত ছড়িয়ে পড়ে কারণ এটি উৎপাদনে দলেরা যা অনুভব করছিলেন তার সঙ্গে মেলে: বিতরণকৃত সিস্টেম কেবল ডাউন হয়ে যায় না; সেগুলো বিভক্ত হয়ে যায়।
CAP সবচেয়ে বেশি কাজে লাগে যখন জিনিস খারাপ হয়—বিশেষত যখন নেটওয়ার্ক আচরণ করে না। স্বাভাবিক দিনে বহু সিস্টেম একসাথে যথেষ্ট সামঞ্জস্যপূর্ণ ও প্রাপ্য মনে হতে পারে। পরীক্ষা তখনই সত্যিকারের—যখন মেশিনগুলো নির্ভরযোগ্যভাবে যোগাযোগ করতে পারে না এবং আপনাকে সিদ্ধান্ত নিতে হবে পার্টিশনের সময় রিড ও রাইট নিয়ে কী করা হবে।
এই ফ্রেমটাই CAP-কে একটি জনপ্রিয় মানসিক মডেল হিসেবে দাঁড় করায়: এটি সেরা অনুশীলন নিয়ে তর্ক করে না; বরং একটি স্পষ্ট প্রশ্ন জোর করে—বিভাজনের সময় আমরা কী ত্যাগ করব?
এই নিবন্ধের শেষে আপনি সক্ষম হবেন:
CAP টিকে বহাল রাখে কারণ এটি "বিতরণকৃত হওয়া কঠিন" কথাটিকে একটি রক্ষা করা সিদ্ধান্তে রূপান্তর করে—এবং তা আপনি দাঁড়িয়ে ব্যাখ্যা করতে পারবেন।
একটি বিতরণকৃত সিস্টেম সরল ভাষায় হলো একাধিক কম্পিউটার একটি একক সিস্টেম আচরণ করার চেষ্টা করছে। আপনার কাছে কয়েকটি সার্ভার থাকতে পারে বিভিন্ন র্যাক, রিজিয়ন বা ক্লাউড জোনে, কিন্তু ব্যবহারকারীর কাছে এটি "অ্যাপ" বা "ডেটাবেস"।
রিয়াল-ওয়ার্ল্ড স্কেলে সেই শেয়ারড সিস্টেম কাজ করতে হলে আমরা সাধারণত প্রতিলিপি করি: একই ডেটার একাধিক কপি বিভিন্ন মেশিনে রাখি।
প্রতিলিপির জনপ্রিয়তার তিনটি বাস্তবিক কারণ:
এখন পর্যন্ত, প্রতিলিপি যেন সরল জয় মনে হচ্ছে। কিন্তু কিছুকাল পর দেখা যায় প্রতিলিপি একটি নতুন কাজ তৈরি করে: সব কপিকে একমত রাখা।
যদি প্রত্যেকে রেপ্লিকা সবসময় একে অপরের সাথে ত্রুটিহীনভাবে কথা বলতে পারত, তারা আপডেটগুলিতে সমন্বয় করে একই অবস্থায় থাকতে পারত। কিন্তু বাস্তব নেটওয়ার্ক নিখুঁত নয়। মেসেজ বিলম্বিত হতে পারে, হারিয়ে যেতে পারে, বা ফেইলারের চারপাশ দিয়ে রুট হতে পারে।
যোগাযোগ স্বাস্থ্যকর হলে রেপ্লিকাগুলো সাধারণত আপডেট বিনিময় করে সমবতী হয়ে ওঠে। কিন্তু যোগাযোগ ভেঙে গেলে (অল্প সময়ের জন্য হলেও), আপনি দুইটি বৈধ-দেখা করা “সত্য” সংস্করণ পেতে পারেন।
উদাহরণ: একজন ব্যবহারকারী তার চালান ঠিকানা পরিবর্তন করে। রেপ্লিকা A আপডেট পায়, রেপ্লিকা B পায় না। এখন সিস্টেমকে সহজ প্রশ্নের উত্তর দিতে হবে: বর্তমান ঠিকানাটি কী?
এটাই পার্থক্য:
CAP চিন্তা ঠিক এখান থেকেই শুরু করে: প্রতিলিপি একবার হলে, যোগাযোগ বিঘ্নে অমিল আর এজ কেস নয়—এটি কেন্দ্রীয় ডিজাইন সমস্যা।
CAP হল একটি মানসিক মডেল যা বলেে যে ব্যবহারকারী বাস্তবে কেমন অনুভব করে যখন সিস্টেম অনেক মেশিনে ছড়িয়ে থাকে (প্রায়ই বিভিন্ন লোকেশনে)। এটা “ভালো” বা “খারাপ” সিস্টেম নির্ধারণ করে না—শুধু সেই টানাপোড়েন আপনাকে কীভাবে পরিচালনা করতে হবে তা বোঝায়।
সামঞ্জস্য হলো একমত থাকার ব্যাপার। আপনি যদি কিছু আপডেট করেন, তখন কি পরের রিড (যেকোনো জায়গা থেকে) সেই আপডেট প্রতিফলিত করবে?
ব্যবহারকারীর কাছে এটি পার্থক্য “আমি এটা ঠিক করেছি, এবং সবাই নতুন মানটা দেখছে” বনাম “কেউ কেউ এখনও পুরনো মান দেখছে”।
প্রাপ্যতা মানে সিস্টেম অনুরোধগুলোর—রিড এবং রাইট—সফল ফলাফল দিয়ে প্রতিক্রিয়া দেয়। বলতে হচ্ছে না “সবচেয়ে দ্রুত”; বলছে “এটি আপনাকে সেবা দিতে অস্বীকার করে না।”
সমস্যার সময় (একটি সার্ভার ডাউনে, নেটওয়ার্ক হিক-আপ), একটি প্রাপ্য সিস্টেম অনুরোধ গ্রহণ করতে থাকে, এমনকি যদি উত্তর একটু পুরানো হয়ে থাকে।
পার্টিশন হলো যখন নেটওয়ার্ক বিভক্ত হয়: মেশিনগুলো চলছে, কিন্তু তাদের মধ্যে কিছু মেসেজ পৌঁছাতে পারে না (বা খুব দেরিতে পৌঁছায়)। বিতরণকৃত সিস্টেমে আপনি এটিকে অসম্ভব বলে বিবেচনা করতে পারবেন না—আপনাকে এটি ঘটলে কী করা হবে তা নির্ধারণ করতে হবে।
ধরা যাক দুইটি রিটেল শপ একই পণ্য বিক্রি করে এবং তাদের “1 ইনভেন্টরি কাউন্ট” শেয়ার। একজন ক্রেতা দোকান A-তে শেষ আইটেমটা কিনে, তাই দোকান A লেখে inventory = 0। একই সময়ে একটি নেটওয়ার্ক পার্টিশন দোকান B-কে এটি জানাতে বাধা দেয়।
যদি দোকান B প্রাপ্যতা বজায় রাখে, তাহলে এটি এমন একটি আইটেমও বিক্রি করতে পারে যা আর নেই (বিভাজিত অবস্থায় সেল গ্রহণ করবে)। যদি দোকান B সামঞ্জস্য বজায় রাখে, তাহলে এটি বিক্রয় প্রত্যাখ্যান করতে পারে যতক্ষণ না এটি সর্বশেষ ইনভেন্টরি নিশ্চিত করতে পারে (স্প্লিট চলাকালীন সার্ভিস অস্বীকার করবে)।
“পার্টিশন” মানে শুধু “ইন্টারনেট ডাউন” নয়। এটি এমন যেকোনো পরিস্থিতি যেখানে আপনার সিস্টেমের অংশগুলো নির্ভরযোগ্যভাবে একে অপরকে বলতে পারে না—যদিও প্রতিটি অংশ ঠিকঠাক চালু থাকতে পারে।
প্রতিলিপিযুক্ত সিস্টেমে, নোডগুলো ক্রমাগত মেসেজ বিনিময় করে: রাইট, স্বীকৃতি, হার্টবিট, লিডার নির্বাচন, রিড রিকোয়েস্ট। একটি পার্টিশন হলো যখন সেই মেসেজগুলো পৌঁছানো বন্ধ করে দেয় (অথবা দেরিতে পৌঁছে), ফলে বাস্তবতা সম্পর্কে অমিল সৃষ্টি হয়: “রাইটটি ঘটেছে কিনা?” “কে লিডার?” “নোড B জীবিত কি না?”
যোগাযোগ অগোছালো, আংশিক উপায়ে ব্যর্থ হতে পারে:
গুরুত্বপূর্ণ পয়েন্ট: পার্টিশন প্রায়ই অবনতি—পূর্ণ অন/অফ আউটেজ নয়। অ্যাপ্লিকেশনের দৃষ্টিকোণ থেকে, “পর্যাপ্ত ধীর” হওয়া প্রায়ই “ডাউন” হওয়ার সমান।
আপনি যত বেশি মেশিন, নেটওয়ার্ক, রিজিয়ন এবং চলমান উপাদান যোগ করবেন, যোগাযোগ ভেঙে পড়ার সুযোগও তত বাড়ে। যদিও পৃথক উপাদানগুলি নির্ভরযোগ্য, সামগ্রিক সিস্টেম আরও নির্ভরতা এবং ক্রস-নোড সমন্বয় থাকার কারণে ব্যর্থতা অনুভব করে।
নিয়ন্ত্রিত কোন নির্দিষ্ট ব্যর্থতার হার ধরে না রাখলেও বাস্তবতা হল: আপনার সিস্টেম যদি পর্যাপ্ত সময় ধরে এবং পর্যাপ্ত পরিকাঠামো ছড়িয়ে থাকে, পার্টিশন ঘটবেই।
পার্টিশন টলারেন্স মানে আপনার সিস্টেম এমনভাবে ডিজাইন করা যাতে এটি বিভাজনের সময় পরিচালনা চালিয়ে রাখে—এমনকি যখন নোডগুলো একে অপরের যা দেখেছে তা নিশ্চিত করতে পারে না। এর ফলে একটি সিদ্ধান্ত নিতেই হয়: অনুরোধ গ্রহণ করা চালিয়ে যাবে (অসামঞ্জস্যের ঝুঁকি নিয়ে) না কি কিছু অনুরোধ বন্ধ/প্রত্যাখ্যান করা হবে (সামঞ্জস্য রক্ষা করে)।
একবার প্রতিলিপি থাকলে, একটি পার্টিশন কেবল একটি যোগাযোগ ভাঙা: আপনার সিস্টেমের দুটি অংশ নির্দিষ্ট সময়ের জন্য একে অপরের সাথে নির্ভরযোগ্যভাবে কথা বলতে পারে না। রেপ্লিকা এখনও চলছে, ব্যবহারকারীরা ক্লিক করছে, এবং আপনার সার্ভিস অনুরোধ পাচ্ছে—কিন্তু রেপ্লিকাগুলো সর্বশেষ সত্যে একমত হতে পারে না।
CAP টানাপোড়েন এক বাক্যে: একটি পার্টিশনের সময় আপনাকে সামঞ্জস্য (C) নাকি প্রাপ্যতা (A) অগ্রাধিকার দেবেন তা বেছে নিতে হবে। একসাথে আপনি দুইটিই পেতে পারবেন না।
আপনি বলছেন: “আমি প্রতিক্রিয়াশীল হওয়ার চেয়ে সঠিক থাকা বেশি চাই।” যখন সিস্টেম নিশ্চিত করতে পারে না যে একটি অনুরোধ সব রেপ্লিকায় সিঙ্ক থাকবে, তখন এটি ব্যর্থ হবে বা অপেক্ষা করবে।
প্রায়োগিক প্রভাব: কিছু ব্যবহারকারী ত্রুটি, টাইমআউট বা “আবার চেষ্টা করুন” বার্তা দেখবে—বিশেষত ডেটা পরিবর্তন অপারেশনের সময়। এটি সাধারণ যখন আপনি দ্বিগুণ চার্জ হওয়ার ঝুঁকি নিতে চান না, বা কোনো আসন ওভারসেল করতে চান না।
আপনি বলছেন: “আমি ব্লক করার চেয়ে উত্তর দেওয়াকে অগ্রাধিকার দেব।” পার্টিশনের প্রতিটি অংশ অনুরোধ গ্রহণ করতে থাকবে, এমনকি যদি তারা সমন্বয় করতে না পারে।
প্রায়োগিক প্রভাব: ব্যবহারকারীরা সফল প্রতিক্রিয়া পাবে, কিন্তু পড়া ডেটা স্টাল হতে পারে এবং সমসাময়িক আপডেটগুলো কনফ্লিক্ট করতে পারে। পরে আপনি রিকনসিলিয়েশনের উপর নির্ভর করবেন (মার্জ রুল, লাস্ট-রাইট-উইনস, ম্যানুয়াল রিভিউ ইত্যাদি)।
এটি সবসময় একটি গ্লোবাল সেটিং না। অনেক প্রোডাক্ট কৌশল মিশ্রিত করে:
মূল বিষয়: প্রতিটি অপারেশনের জন্য সিদ্ধান্ত নিন—এখন একজন ব্যবহারকারী ব্লক হওয়া খারাপ নাকি পরে কনফ্লিক্ট মেরামত করা খারাপ।
“দুটি বেছে নিন” স্লোগান মনে রাখতে সহজ, কিন্তু এটি প্রায়ই মানুষকে ভুল বোঝায় যে CAP হলো তিনটি ফিচারের একটি মেনু যেখানে আপনি চিরতরে মাত্র দুইটি রাখতে পারবেন। CAP মূলত বলে কি হয় যখন নেটওয়ার্ক সহযোগিতা বন্ধ করে দেয়: পার্টিশনের সময় একটি বিতরণকৃত সিস্টেমকে রিডের জন্য সামঞ্জস্যপূর্ণ উত্তর দেওয়া নাকি প্রতিটি অনুরোধের জন্য প্রাপ্য থাকা—এই দুইটার মধ্যে বেছে নিতে হয়।
বাস্তব বিতরণকৃত সিস্টেমে, পার্টিশন একটি সেটিং নয় যা আপনি নিষ্ক্রিয় করতে পারবেন। যদি আপনার সিস্টেম মেশিন, র্যাক, জোন বা রিজিয়ন জুড়ে ছড়িয়ে পড়ে, তবে বারবার বার্তা বিলম্বিত, হারানো বা পুনরায় অর্ডার হতে পারে। এটি সফটওয়্যারের দৃষ্টিকোণ থেকে একটি পার্টিশন।
এven যদি ফিজিক্যাল নেটওয়ার্ক ঠিকঠাক থাকে, অন্যান্য ব্যর্থতা একই প্রভাব তৈরি করে—ওভারলোডেড নোড, GC পজ, নইজি নেবরস, DNS সমস্যা, অস্থির লোড ব্যালান্সার। ফলাফল একই: সিস্টেমের কিছু অংশ অন্য অংশের সাথে পর্যাপ্তভাবে সমন্বয় করতে পারে না।
অ্যাপ্লিকেশনগুলোর কাছে “পার্টিশন” হলো একটি পরিমিত, বাইনারি ইভেন্ট নয়। তারা অনুভব করে লেটেন্সি স্পাইক এবং টাইমআউট। যদি একটি রিকোয়েস্ট ২০০ মি.সে. পরে টাইমআউট হয়, সেটি পার্থক্য করে না প্যাকেট ২০১ মি.সে. এ পৌঁছেছে নাকি কখনো পৌঁছায়নি: অ্যাপকে পরবর্তী পদক্ষেপ ঠিক করতে হয়। অ্যাপের দৃষ্টিকোণ থেকে ধীর যোগাযোগ প্রায়ই ভাঙা যোগাযোগের সমান।
অনেক বাস্তব সিস্টেম প্রধানত সামঞ্জস্যপূর্ণ বা প্রধানত প্রাপ্য হতে পারে, কনফিগারেশন ও অপারেটিং অবস্থার ওপর নির্ভর করে। টাইমআউট, রিট্রাই নীতি, কোয়ারাম সাইজ, এবং “read your writes” বিকল্পগুলি আচরণ সরানোতে পারে।
স্বাভাবিক অবস্থায় একটি ডাটাবেস শক্তভাবে সামঞ্জস্যপূর্ণ মনে হতে পারে; সঙ্কটের সময় বা ক্রস-রিজিয়ন হিক-আপে এটি রিকোয়েস্ট ফেইল করতে পারে (সামঞ্জস্যকে অগ্রাধিকার দেয়) বা পুরানো ডেটা ফেরত দিতে পারে (প্রাপ্যতাকে অগ্রাধিকার দেয়)।
CAP পণ্যের লেবেল দেয়ার চেয়ে বেশি—এটি বোঝার বিষয় আপনি কোনো বিবাদে কী ট্রেড নিচ্ছেন, বিশেষত যখন সেই বিবাদ সাধারণ ধীরতার কারণে উদ্ভূত।
CAP আলোচনা প্রায়ই সামঞ্জস্যকে সর্বচ্ছন্ন বা পুরোপুরি অনিয়ন্ত্রিত ভাবতে বাধ্য করে। বাস্তব সিস্টেমগুলো গ্যারান্টির একটি মেনু অফার করে, প্রতিটিই বিভাজন বা যোগাযোগ ব্যর্থতার সময় ভিন্ন ব্যবহারকারী অভিজ্ঞতা দেয়।
শক্ত সামঞ্জস্য (প্রায়ই "linearizable") মানে: একবার একটি রাইট স্বীকৃত হলে, যে কোনো পরে রিড—যে রেপ্লিকাই হোক না কেন—এই রাইটটি ফেরত দেবে।
এর দাম: একটি পার্টিশন বা গরিষ্ঠ রেপ্লিকার অনুপলব্ধ হলে সিস্টেম রিড/রাইট বিলম্ব বা প্রত্যাখ্যান করতে পারে যাতে বিরোধ এড়ানো যায়। ব্যবহারকারীরা এটিকে টাইমআউট, “আবার চেষ্টা করুন” বা সাময়িক রিড-ওনলি হিসেবে দেখবে।
অবশেষে সামঞ্জস্য প্রতিশ্রুতি দেয় যে যদি আর নতুন আপডেট না ঘটে, সব রেপ্লিকা মিলবে। এটা গ্যারান্টি করে না যে দুই ব্যবহারকারী ঠিক এখন একই জিনিস দেখবে।
ব্যবহারকারীরা দেখতে পারেন: সদ্য আপডেট করা প্রোফাইল ছবি কিছুকাল পরে "ফিরে যায়", কাউন্টারগুলো বিলম্ব করে আপডেট হয়, বা ঠিক এখন পাঠানো একটি মেসেজ অন্য ডিভাইসে কিছুকাল পরে দেখা যায়।
আপনি প্রায়ই পুরো শক্ত সামঞ্জস্য ছাড়াও ভাল ব্যবহারকারি অভিজ্ঞতা কিনতে পারেন:
এই গ্যারান্টিগুলি মানুষের চিন্তাভাবনার সঙ্গে ভালভাবে মানায় ("আমার নিজের পরিবর্তন হারিয়ে যাবে না") এবং আংশিক ব্যর্থতার সময় রক্ষা করা তুলনায় সহজ।
ব্যবহারকারীর প্রতিশ্রুতি থেকে শুরু করুন, জার্গন থেকে নয়:
সামঞ্জস্য একটি পণ্য-সিদ্ধান্ত: ব্যবহারকারীর জন্য “ভুল” কী তা সংজ্ঞায়িত করুন, তারপর সেই ভুল প্রতিহত করার জন্য সবচেয়ে দুর্বল গ্যারান্টি বেছে নিন।
CAP-এ প্রাপ্যতা কোনো প্রচারসংক্রান্ত সংখ্যা (“ফাইভ নাইনস”) নয়—এটা একটি প্রতিশ্রুতি যা আপনি ব্যবহারকারীর প্রতি দেন যখন সিস্টেম নিশ্চিত নয়।
রিপ্লিকাগুলো একমত না হলে প্রায়ই আপনি বেছে নেন:
ব্যবহারকারীরা এটিকে “অ্যাপ কাজ করছে” বনাম “অ্যাপ সঠিক” হিসেবে অনুভব করে। একটি সামান্য পুরানো সোশ্যাল ফিড বিরক্তিকর; একটি পুরানো অ্যাকাউন্ট ব্যালান্স ক্ষতিকর।
অনিশ্চয়তার সময় দুটি সাধারণ আচরণ:
এটি শুধুমাত্র প্রযুক্তিগত নয়; এটি একটি পলিসি সিদ্ধান্ত। পণ্যকে নির্ধারণ করতে হবে কী দেখানো গ্রহণযোগ্য, আর কী কখনো অনুমান করা যাবেনা।
প্রাপ্যতা জটলা কদাচিৎ সব-অথবা-কিছু নয়। বিভাজনের সময় আপনি দেখতে পারেন আংশিক প্রাপ্যতা: কিছু রিজিয়ন, নেটওয়ার্ক বা ব্যবহারকারী গ্রুপ সফল হয় আর অন্যরা ব্যর্থ হয়। এটি ইচ্ছাকৃত ডিজাইন হতে পারে (স্থানীয় রেপ্লিকা যেখানে স্বাস্থ্যবান সেখানে সার্ভ করা) বা দুর্ঘটনাজনিত (রাউটিং ভারসাম্যহীনতা, অসম কোয়ারাম অ্যাক্সেস)।
একটি বাস্তবসম্মত মাঝামাঝি হল ডিগ্রেড মোড: নিরাপদ ক্রিয়াগুলো চালু রেখে ঝুঁকিপূর্ণগুলো সীমাবদ্ধ রাখুন। উদাহরণস্বরূপ, ব্রাউজ ও সার্চ চালু রাখুন, কিন্তু সাময়িকভাবে “ট্রান্সফার ফান্ডস”, “পাসওয়ার্ড বদলানো” বা অন্য ঝুঁকিপূর্ণ অপারেশন বন্ধ করে দিন।
CAP একটি মানসিক মডেল যা যোগাযোগ বিঘ্নের সময় প্রতিলিপিযুক্ত সিস্টেম নিয়ন্ত্রণ করতে সাহায্য করে। এটা সবচেয়ে কাজে লাগে যখন নেটওয়ার্ক ধীর, প্যাকেট হারায় বা বিভাজিত হয়, কারণ তখন রেপ্লিকাগুলি নির্ভরযোগ্যভাবে একমত হতে পারে না এবং আপনাকে নিচের দুইটির মধ্যে সিদ্ধান্ত নিতে হয়:
এই মডেলটি "বিতরণকৃত সিস্টেম জটিল" কথাটিকে একটি স্পষ্ট প্রোডাক্ট ও ইঞ্জিনিয়ারিং সিদ্ধান্তে রূপান্তর করে।
একটি সত্যিকারের CAP পরিস্থিতির জন্য দরকার উভয়ই:
আপনি যদি একটি একক নোডে চলেন, বা স্টেট রেপ্লিকেট না করেন, তাহলে CAP ট্রেডঅফগুলো প্রধান সমস্যা নয়।
পার্টিশন বলতে এমন কোনো পরিস্থিতিকে বোঝায় যেখানে সিস্টেমের অংশগুলো নির্ভরযোগ্যভাবে বা প্রয়োজনীয় সময়সীমার মধ্যে যোগাযোগ করতে পারে না—যদিও প্রতিটি মেশিন এখনও চালু থাকতে পারে।
বাস্তবে, “পার্টিশন” প্রায়শই এভাবে প্রকাশ পায়:
অ্যাপের দৃষ্টিকোণ থেকে, “খুব ধীর” হওয়া অনেক সময় “ডাউন” হওয়ার সমান।
Consistency (C) মানে হলো রিডগুলো স্বীকৃত সর্বশেষ রাইট প্রতিফলিত করে—অর্থাৎ সবাই একই সর্বশেষ মান দেখে। ব্যবহারকারীর অভিজ্ঞতায় এটি হয় “আমি এটি বদলেয়েছি, এবং সবাই একই নতুন মান দেখছে।”
Availability (A) মানে হলো প্রত্যেক অনুরোধ একটি সফল প্রতিক্রিয়া পায় (অবশ্যই সর্বশেষ ডেটা নাও হতে পারে)। ব্যবহারকারী এটি অনুভব করে “অ্যাপটি চালু আছে,” কেবল কিছু ফলাফল আগের হতে পারে।
একটি পার্টিশনের সময় সাধারণত আপনি উভয়ই একসাথে গ্যারান্টি করতে পারবেন না।
কারণ পার্টিশন বিতরণকৃত সিস্টেমে ঐচ্ছিক নয়—যদি আপনি মেশিন, র্যাক, জোন বা রিজিয়ন জুড়ে প্রতিলিপি করেন, তাহলে নোডগুলো কখনো না কখনো সমন্বয় করতে অসফল হবে।
"পার্টিশনকে উপেক্ষা করা" সম্ভব নয়—আপনি প্রতিবার যোগাযোগ বিঘ্ন ঘটলে কী করবেন তা নির্দিষ্ট করে রাখতে হবে। সাধারণত তা হয়: কিছু অ্যাকশন প্রত্যাখ্যান/বিলম্বিত করা (সামঞ্জস্যকে বেছে নেওয়া) অথবা বেষ্ট-এফফর্ট ফলাফল দেখানো (প্রাপ্যতাকে বেছে নেওয়া)।
যদি আপনি সামঞ্জস্য (Consistency) কে অগ্রাধিকার দেন, তাহলে সাধারণত আপনি:
এটি সাধারণত টাকা লেনদেন, ইনভেন্টরি রিজার্ভেশন বা অনুমতি পরিবর্তনের মতো ক্ষেত্রে ব্যবহৃত হয়—যেখানে ভুল হওয়া ক্ষতির চেয়ে ইন্টারাপশন গ্রহণযোগ্য।
যদি আপনি প্রাপ্যতা (Availability) কে অগ্রাধিকার দেন, তাহলে সাধারণত আপনি:
ব্যবহারকারীরা কম হার্ড এরর দেখবে, কিন্তু স্টেল ডেটা, ডুপ্লিকেট ইফেক্ট (যদি আইডেমপোটেন্সি না থাকে), অথবা কনফ্লিক্ট যা পরে ক্লিনআপ প্রয়োজন—এগুলো দেখা যেতে পারে।
হ্যাঁ। আপনি প্রতিটি এন্ডপয়েন্ট বা ডেটা টাইপ অনুযায়ী আলাদা সিদ্ধান্ত নিতে পারেন। প্রচলিত মিক্সড কৌশলগুলো:
এভাবে একটি একক “আমরা AP/CP” লেবেল এড়ানো যায়, যা বাস্তবে প্রায়ই উপযুক্ত হয় না।
আপনি বেছে নিতে পারেন:
প্রশ্ন হলো: একটি বিভাজনের সময় আপনার ব্যবহারকারীরা কী অনুভব করবে—আপনি সিস্টেমকে প্রতিক্রিয়া দেখাতে চান না কি ভুল ডেটা থেকে বিরত রাখতে চান?
সংক্ষেপে: আপনার ব্যবসায়িক খরচ কত—এই সিদ্ধান্তটাই নির্ধারণ করে।
যদি আপনি বিভাজনের সময় আপনার সিদ্ধান্তগুলো বাস্তব করে তুলতে চান, তাহলে সাধারণভাবে ব্যবহৃত কিছু নকশাগত প্যাটার্ন আছে:
সিস্টেমটি কিভাবে আচরণ করবে তা নিশ্চিত করতে আপনি ইচ্ছাকৃতভাবে সেই পরিস্থিতি তৈরি করে পরীক্ষা করবেন:
নির্দিষ্টভাবে প্রশ্নগুলো জিজ্ঞাসা করুন:
প্রতিটি ডেটা টাইপ ও এন্ডপয়েন্ট আলাদাভাবে নির্ধারণ করুন—গ্লোবাল “আমরা AP” বলা এড়ান।
এবং সবশেষে: পার্টিশন হারিয়ে গেলে কী ধরনের অসঙ্গতি আপনি গ্রহণ করতে পারেন তা স্পষ্টভাবে বর্ণনা করুন (সময়সীমা, পরিমাণ, ক্ষেত্র-নির্ভর সীমা) এবং ব্যবহারকারীকে কী দেখাবেন তা নির্ধারণ করুন।
আপনি এমন দুর্বলতম গ্যারান্টি বাছাই করুন যা ব্যবহারকারী-দৃষ্টিতে অগ্রহণযোগ্য “ভুল” প্রতিরোধ করে।