আধুনিক লেনদেন স্ট্যাক

লেনদেন সংক্রান্ত ডাটাবেসগুলি দীর্ঘকাল ধরে অ্যাপ্লিকেশন ডিজাইনের সবচেয়ে গুরুত্বপূর্ণ উপাদান। কেন? কারণ একটি অবিচলিত ডাটাবেস সাধারণত একটি অগোছালো, বিতরণ করা বিশ্বে সঠিকতার জন্য চূড়ান্ত প্রয়োগকারী পয়েন্ট। তাদের ছাড়া আমরা অতিরিক্ত অর্থ প্রদান এবং কম চার্জ করব। আমরা বিমানবন্দর থেকে বাড়ি যাওয়ার চেষ্টাকারী রাইডারদের হারাবো, এবং আমরা আমাদের শপিং কার্টে আইটেম হারাবো। আমাদের অনলাইন অ্যাকাউন্টগুলি হারিয়ে যাবে, সদৃশ হয়ে যাবে বা দূষিত হবে এবং অকার্যকর হয়ে যাবে। 

প্রকৃতপক্ষে, লেনদেন সংক্রান্ত ডাটাবেস (সাধারণত OLTP বলা হয় — অনলাইন লেনদেন প্রক্রিয়াকরণের জন্য সংক্ষিপ্ত — ডাটাবেস) অ্যাপ্লিকেশন ডেভেলপমেন্টে এতটাই কেন্দ্রীভূত হয়েছে যে, সময়ের সাথে সাথে এটি আরও বেশি করে অ্যাপ্লিকেশন কার্যকারিতা গ্রহণ করেছে। যাইহোক, মাইক্রোসার্ভিস এবং অন্যান্য আধুনিক অ্যাপ্লিকেশন আর্কিটেকচারগুলি অ্যাপ্লিকেশন ডিজাইনে নতুন জটিলতার সূচনা করেছে: ডেভেলপারদের বিভিন্ন পরিষেবা জুড়ে ডেটা পরিচালনা করতে এবং তাদের মধ্যে সামঞ্জস্যতা নিশ্চিত করতে হবে, যা তাদের ঘরে জটিল ডেটা সিঙ্ক্রোনাইজেশন এবং প্রক্রিয়াকরণ প্রক্রিয়া তৈরি করতে বাধ্য করেছিল। 

এবং তাই, একটি শিল্প হিসাবে, আমরা ক্রমবর্ধমান সচেতনতা দেখছি যে ঐতিহ্যগত মডেলের বাইরে লেনদেনের গ্যারান্টি প্রয়োজন। আমরা দেখছি সিস্টেমের উত্থান যা ডাটাবেসের বাইরে, বিতরণ করা অ্যাপগুলিতে শক্তিশালী লেনদেন গ্যারান্টি প্রসারিত করে. 

আমরা গত কয়েক বছর ধরে এই সমাধানগুলি ট্র্যাক করছি। সাধারণত, তারা স্কেলিং চ্যালেঞ্জ তৈরি না করে এবং একটি আধুনিক প্রোগ্রামিং পরিবেশ প্রদান না করে একটি বৃহৎ বিতরণ করা অ্যাপে রাষ্ট্রের লেনদেন পরিচালনার অনুমতি দেওয়ার চেষ্টা করে। 

আমরা এই সমাধানগুলিকে মোটামুটিভাবে দুটি বিভাগে বিভক্ত দেখতে পাই। একটি বিভাগ হল কর্মপ্রবাহ অর্কেস্ট্রেশন. এটি মূলত গ্যারান্টি দেয় যে কোডের একটি ব্লক সম্পূর্ণ হবে, এমনকি ব্যর্থতার মুখেও। সুতরাং এটি একটি বিতরণ করা রাষ্ট্রের যন্ত্রকে নির্ধারকভাবে পরিচালনার উদ্দেশ্যে ব্যবহার করা যেতে পারে। দ্বিতীয় বিভাগ হল ডাটাবেস + ওয়ার্কফ্লো, যা প্রথাগত OLTP ডাটাবেস ডিজাইনকে প্রসারিত করে, একই উদ্দেশ্যে নির্বিচারে কোড কার্যকর করার অনুমতি দেয়। 

এটি এখনও একটি খুব নবজাত এলাকা, এবং নামকরণের চারপাশে অনেক বিভ্রান্তি রয়েছে, প্রতিটি সরঞ্জাম কীভাবে ব্যবহার করা হয় এবং কাদের ব্যবহার করা উচিত। আরও ভালোভাবে বোঝার জন্য, আমরা নেতৃস্থানীয় প্রকৌশলী প্রতিষ্ঠানের অনুশীলনকারীদের তাদের লেনদেন সংক্রান্ত স্ট্যাক এবং কীভাবে তারা লেনদেন সংক্রান্ত কাজের চাপের জন্য তিনটি মূল ধারণা সম্পর্কে ভাবছে সে সম্পর্কে জিজ্ঞাসা করেছি: অ্যাপ্লিকেশনের অবস্থা, ব্যবসায়িক যুক্তি এবং ব্যবসার ডেটা। 

এই নতুন স্ট্যাকগুলি পরীক্ষা করার আগে, যদিও, আমরা এখানে কীভাবে এসেছি তা বুঝতে সাহায্য করার জন্য এখানে একটি দ্রুত আধা-প্রযুক্তিগত ডিগ্রেশন দেওয়া হল।

লেনদেন, গ্যারান্টি এবং আধুনিক অ্যাপ 

খুব মোটামুটি সংস্করণ হল: এখানে এক সেট কাজ রয়েছে — লেনদেন — যেগুলো আপনি হয় সব করতে চান, না হয় কোনোটিই করতে চান না। এর মধ্যে যেকোনো কিছু (এটি আংশিকভাবে সম্পন্ন করা) একটি দুর্নীতিগ্রস্ত অবস্থায় শেষ হবে। এটা নিশ্চিত করা কঠিন কিছু একটি বিতরণ সিস্টেমে, কিন্তু ডাটাবেস লেনদেনের সাথে এটি ভাল করে। অতএব, অনেক সিস্টেমে গ্যারান্টিগুলি পরিচালনা করার সবচেয়ে সহজ উপায় হল বেশিরভাগ জিনিসের লেনদেন করা এবং ডাটাবেসকে সেগুলি পরিচালনা করা।

আধুনিক অ্যাপ্লিকেশানগুলি হল বিশাল বিতরণ করা সিস্টেম যার সাথে অনেক ব্যবহারকারী অনেক কিছু করে৷ সুতরাং এমনকি অ্যাপটিকে সামঞ্জস্যপূর্ণ রাখা (যেমন ট্র্যাকিং যেখানে বিভিন্ন ব্যবহারকারী চেক-আউট প্রবাহে রয়েছে) একটি বিতরণ করা লেনদেন সমস্যায় পরিণত হয়। ঐতিহ্যগত মনোলিথিক আর্কিটেকচারে, একটি OLTP ডাটাবেসের সাথে SQL ব্যবহার করে লেনদেন পরিচালনা করা কিছুটা কার্যকর ছিল। কিন্তু উচ্চ-স্তরের API-এর (যেমন REST বা gRPC) মাধ্যমে ইন্টারঅ্যাক্ট করা মাইক্রোসার্ভিসের নতুন, জটিল জগতে, লেনদেনের চাহিদা প্রকৃতিতে বিতরণ করা হয়েছে। 

যাইহোক, মাইক্রোসার্ভিসে যাত্রা শুরু করা অনেক কোম্পানি ডাটাবেসের বাইরে শক্তিশালী লেনদেন গ্যারান্টি প্রসারিত করার জন্য খুব বেশি কিছু করেনি। এবং, অনুশীলনে, যে প্রায় সবসময় ঠিক আছে. কিন্তু অ্যাপ্লিকেশান স্কেল হিসাবে, ডেটাতে অসঙ্গতি বাড়তে থাকে, ফলে ব্যবসায়িক ডেটাতে ত্রুটি এবং অ-মিলনযোগ্য ত্রুটিগুলিও বৃদ্ধি পায়। যা, অবশ্যই, ব্যাপক সমস্যাযুক্ত হতে পারে। এটি অ্যাপ্লিকেশন বিকাশকারীদের বিস্তৃত ব্যর্থতার পরিস্থিতি এবং দ্বন্দ্ব সমাধানের কৌশলগুলির সাথে মোকাবিলা করতে এবং বিভিন্ন স্থাপত্য নিদর্শনগুলির মাধ্যমে তাদের নিজস্ব কৌশলগুলি নিয়ে এসে রাষ্ট্রের ধারাবাহিকতা নিশ্চিত করতে বাধ্য করে।

সংজ্ঞা ব্যবসার তথ্য ("ডেটা") অধ্যবসায় এবং প্রক্রিয়াকরণের জন্য ঐতিহ্যগতভাবে একটি OLTP ডাটাবেসে সংরক্ষিত ব্যবসা-সমালোচনামূলক ডেটা বোঝায় (যেমন ব্যবহারকারীর প্রোফাইল তথ্য যেমন নাম, ঠিকানা, ক্রেডিট স্কোর ইত্যাদি)। আবেদনের অবস্থা সিস্টেমের বর্তমান অবস্থা বোঝায়; অ্যাপ্লিকেশন অবস্থা একটি ডেটা স্টোরেজ সিস্টেমে সঞ্চিত একটি মান দ্বারা নির্ধারিত হয় এবং একটি সীমিত স্টেট মেশিনে কোন ধাপে প্রোগ্রামটি কার্যকর করা হয় (যেমন একটি অর্ডারের অবস্থা, যেমন "অর্ডার প্রাপ্ত", "ইনভেন্টরি চেক করা হয়েছে," "ক্রেডিট চেক করা হয়েছে) ," "চালিত," "ফেরত")। ব্যবসায়িক যুক্তি প্রোগ্রামের অংশটিকে বোঝায় যেটি কার্য সম্পাদনের বিবরণের পরিবর্তে অ্যাপ্লিকেশনটি আসলে কীভাবে কাজ করে বা এটি কী করে তা নিয়ে কাজ করে (যেমন "যদি ব্যবহারকারী_আয় > $100K এবং ক্রেডিট_স্কোর >650 ⇒ বন্ধকী_অনুমোদিত = সত্য")।

এই আলোচনার উদ্দেশ্যে, অ্যাপ্লিকেশানের অবস্থা এবং ব্যবসার ডেটা আলাদা করা গুরুত্বপূর্ণ৷ উদাহরণ স্বরূপ, একজন গ্রাহক তাদের ক্রেডিট কার্ডে প্রবেশ করেছেন কিন্তু চেক আউট করেননি তা জানা হল আবেদনের অবস্থা। ক্রেডিট কার্ডের ডেটা এবং অ্যাপ্লিকেশন কার্টে থাকা আইটেমগুলি হল ব্যবসার ডেটা৷ 

একটি সাধারণ প্রবাহে, একটি অনুরোধ সামনে-প্রান্ত থেকে আসে, প্রমাণীকৃত হয় এবং তারপর একটি API গেটওয়ে বা GraphQL এর মাধ্যমে প্রাসঙ্গিক শেষ পয়েন্টে চলে যায়। 

সেই একক এপিআই এন্ডপয়েন্টকে এখন শেষ-গ্রাহকের কাছে ব্যবসায়িক লেনদেন সরবরাহ করার জন্য দশ, বা শত শত মাইক্রোসার্ভিস অর্কেস্ট্রেট করতে হবে। এখানেই ডেভেলপাররা সাধারণত ব্যবসায়িক লজিক ব্লব-এ সবকিছু একত্রিত করে, এবং তারপর ডাটাবেসে ডেটা পেতে সারি, ক্যাশে এবং হ্যান্ড-কোডেড রিট্রাই মেকানিজমের সংমিশ্রণ ব্যবহার করে — আশা করি সম্পূর্ণ লেনদেন হিসাবে প্রতিশ্রুতিবদ্ধ।

অ্যাপ্লিকেশনের স্কেল বাড়ার সাথে সাথে সারি এবং ক্যাশে পরিচালনার জটিলতা, সেইসাথে সমস্যা দেখা দিলে পুনর্মিলন যুক্তিতে তীক্ষ্ণ প্রান্তের সংখ্যাও বৃদ্ধি পায়। 

কর্মপ্রবাহ-কেন্দ্রিক এবং ডাটাবেস-কেন্দ্রিক লেনদেন স্ট্যাকের উত্থান

ঠিক আছে, তাই লেনদেন গুরুত্বপূর্ণ। একটি ডাটাবেসের LAMP স্কেলের জন্য যথেষ্ট ছিল না। এবং সারি এবং পুনরায় চেষ্টা যুক্তির একটি বিশাল চুলের বল খুবই ভঙ্গুর। এটি মোকাবেলা করার জন্য, আমরা দেখেছি, গত কয়েক বছরে, নতুন সমাধানের আবির্ভাব যা লেনদেনের যুক্তিতে বিচক্ষণতা ফিরিয়ে আনে। এগুলিকে মোটামুটিভাবে কর্মপ্রবাহ-কেন্দ্রিক পন্থা বা ডাটাবেস-কেন্দ্রিক পন্থা হিসাবে শ্রেণীবদ্ধ করা যেতে পারে।

আজ অবধি, ওয়ার্কফ্লো ইঞ্জিনগুলি ব্যবসার ডেটার পরিবর্তে প্রাথমিকভাবে অ্যাপ্লিকেশন স্টেটে কাজ করে এবং প্রথাগত ডাটাবেসের সাথে একীভূত করার সময় প্রায়শই কিছু জটিলতার প্রয়োজন হয়। ডেটাবেস-কেন্দ্রিক পদ্ধতিগুলি ব্যবসায়িক ডেটার পাশাপাশি অ্যাপ্লিকেশন লজিক যোগ করে, কিন্তু এখনও ওয়ার্কফ্লো ইঞ্জিনগুলির একই কোড-নির্বাহের পরিশীলিততা নেই। 

নিচের চিত্রটি একটি জাভাস্ক্রিপ্ট/টাইপস্ক্রিপ্ট অ্যাপ্লিকেশনে ওয়ার্কফ্লো- এবং/অথবা ডাটাবেস-কেন্দ্রিক পন্থাগুলি কীভাবে ব্যবহার করা হয় তার একটি মোটামুটি স্কেচ প্রদান করে, অনুমান করে যে উভয়ই ব্যবহার করা হচ্ছে। যদিও তারা আজ এই আর্কিটেকচারের স্বতন্ত্র অংশ, আমরা একটি প্রবণতার প্রাথমিক লক্ষণ দেখেছি যেখানে ডাটাবেসগুলি ওয়ার্কফ্লো বৈশিষ্ট্যগুলিকে অন্তর্ভুক্ত করছে এবং ওয়ার্কফ্লোগুলি টেকসই স্টোরেজ গ্রহণ করতে শুরু করেছে। ক্ষমতার এই একত্রীকরণ ইঙ্গিত দেয় যে দুটি পদ্ধতির মধ্যে রেখাগুলি ঝাপসা হয়ে যাচ্ছে এবং আধুনিক স্থাপত্যগুলিতে কম স্বতন্ত্র হয়ে উঠছে। 

বিস্তারিতভাবে কর্মপ্রবাহ-কেন্দ্রিক পন্থা 

একটি ওয়ার্কফ্লো হল কোডের ব্লক যা ইভেন্ট বা টাইমারের উপর ভিত্তি করে কার্যকর করে যা অ্যাপ্লিকেশন স্টেট মেশিনকে বিকশিত করে। লেনদেনমূলক কর্মপ্রবাহ দৃঢ় গ্যারান্টি সহ কোড নির্বাহ নিশ্চিত করে, অ্যাপ্লিকেশনে আংশিক বা অনিচ্ছাকৃত অবস্থা প্রতিরোধ করে। বিকাশকারীরা যুক্তি লেখেন, এবং ওয়ার্কফ্লো ইঞ্জিন লেনদেন, মিউটেশন এবং অদম্যতা পরিচালনা করে। বিভিন্ন ওয়ার্কফ্লো ইঞ্জিন ডেভেলপারদের কাছে কতটা লেনদেনের বিশদ প্রকাশ করা হয় তার পরিপ্রেক্ষিতে বিভিন্ন ট্রেড-অফ করে। 

একটি উদাহরণ হিসাবে, নীচে Orkes (কন্ডাক্টর) এ চলমান একটি চেক-আউট কর্মপ্রবাহের একটি ভিজ্যুয়াল উপস্থাপনা রয়েছে: 

সেখানে দুটি রুক্ষ পন্থা যার মাধ্যমে ওয়ার্কফ্লো ইঞ্জিন ট্র্যাকশন লাভ করে। একটিতে (Temporal.io দ্বারা টাইপ করা), বিকাশকারীরা স্ট্যান্ডার্ড ব্যাক-এন্ড প্রোগ্রামিং ভাষা (যেমন গো বা জাভা) ব্যবহার করে কোড লেখেন এবং সিস্টেম নিশ্চিত করবে যে কোডটি সম্পূর্ণ হওয়া পর্যন্ত চলেএমনকি ব্যর্থতার সময়ও। এই মডেলে, কোডটি ব্লকিং কল সম্পূর্ণ হওয়ার জন্য অপেক্ষা করলেও প্রোগ্রাম-কল স্ট্যাক বজায় থাকে (যেমন পড়া বা লেখা)। এটি করার জন্য, ব্যর্থতার সময় আংশিক কোড নির্বাহ রোধ করতে ভাষা রানটাইম পরিবর্তন করা হয়। এই পদ্ধতির উল্টো দিক হল যে ডেভেলপাররা পরিচিত ভাষায় লিখতে পারে এবং একটি রক্ষণাবেক্ষণ করা কল স্ট্যাকের সাথে সহজেই ডিবাগ করতে পারে। আমরা দেখতে পাই যে এই পদ্ধতিটি ব্যাক-এন্ড টিমের সাথে সবচেয়ে জনপ্রিয়, বড়, অত্যাধুনিক অ্যাপগুলির সাথে কাজ করে। 

নেতিবাচক দিক হল যে এটি প্রায়শই অ্যাপ্লিকেশন বিকাশকারীদের কাছে দরকারী এবং নিরাপদ ইন্টারফেসগুলি প্রকাশ করতে প্রচুর ইন্টিগ্রেশন কাজ এবং মোড়ক কোডের প্রয়োজন হয়। আরেকটি নেতিবাচক দিক হল যে এটি খালি ভাষার পরিবর্তে একটি কাস্টম এক্সিকিউশন লেয়ারের উপর নির্ভর করে এবং এমন কিছু ক্ষেত্রে রয়েছে যেখানে এক্সিকিউশন স্থানীয় ভাষার রানটাইম থেকে আলাদা হবে। তাই, যখন ডেভেলপাররা তাদের পরিচিত ভাষা ব্যবহার করতে পারে, তবুও তাদের বুঝতে হবে কিভাবে অন্তর্নিহিত সিস্টেম কাজ করে।  

অন্য পদ্ধতি, যা অ্যাপ্লিকেশন ডেভেলপারদের কাছে বেশি জনপ্রিয় (বিশেষ করে টাইপস্ক্রিপ্ট/জাভাস্ক্রিপ্ট) হল ওয়ার্কফ্লো ইঞ্জিনের জন্য অ্যাসিঙ্ক ফাংশনের অর্কেস্ট্রেটর হিসাবে কাজ করে (যেমন ইনজেস্ট, ডিফার, এবং ট্রিগার)। এই মডেলে, তৃতীয় পক্ষের ইভেন্ট বা ফাংশনগুলি ওয়ার্কফ্লো ইঞ্জিনে নির্দেশিত হয়, যা তারপরে অ্যাপ্লিকেশন প্রোগ্রামারদের দ্বারা নিবন্ধিত লজিক প্রেরণ করবে, যারা অন্য অ্যাসিঙ্ক ফাংশনে ব্লক করার প্রয়োজন দেখা দিলে তাদের অবশ্যই নিয়ন্ত্রণ ফিরিয়ে দিতে হবে। উল্টো দিকটি হল এটি একটি প্রোগ্রামে সংহত করার অনেক বেশি হালকা পদ্ধতি। এটি কোডের উপর যথেষ্ট কাঠামো জোর করে যাতে এটিতে কাজ করা দল এটি আরও সহজে বুঝতে পারে। যাইহোক, এই পদ্ধতির টুলিং সমর্থন ছাড়া ডিবাগ করা আরও কঠিন হতে পারে, তাই ডিবাগিং প্ল্যাটফর্ম-নির্দিষ্ট হতে থাকে।

ওয়ার্কফ্লো ইঞ্জিনগুলি বিশেষভাবে শক্তিশালী যে তারা বিদ্যমান অ্যাপগুলিকে ধীরে ধীরে গ্রহণ করার অনুমতি দেয়। এগুলি ন্যূনতম পদচিহ্ন সহ নির্দিষ্ট কর্মপ্রবাহে টুকরো টুকরো প্রয়োগ করা যেতে পারে। এটি বলেছিল, ওয়ার্কফ্লো ইঞ্জিনগুলির দুটি বৃহত্তম ত্রুটিগুলি এই সত্য থেকে উদ্ভূত হয় যে তারা ডাটাবেসের মধ্যে প্রসারিত হয় না। ফলস্বরূপ, অ্যাপ্লিকেশন রাজ্য এবং ব্যবসায়িক ডেটা জুড়ে সত্যের একটি একক, অনুসন্ধানযোগ্য উত্স নেই৷ এছাড়াও, লেনদেনমূলক শব্দার্থবিদ্যা সাধারণত ডাটাবেস শব্দার্থবিদ্যা থেকে আলাদা, যার জন্য অ্যাপ্লিকেশন বিকাশকারীদের প্রান্তের অবস্থা পরিচালনা করতে হয়। 

যদিও আজকের আদর্শ নয়, আমরা ধারণাগত স্থাপত্যগুলিকে চিত্রিত করতে চাই কিভাবে ওয়ার্কফ্লোগুলি অনেক ক্ষেত্রে স্থায়ী ডেটা স্টোর হিসাবে ব্যবহার করা যেতে পারে:

বিস্তারিতভাবে ডেটাবেস-কেন্দ্রিক পন্থা 

ডেটাবেস-কেন্দ্রিক পন্থাগুলি একটি ডাটাবেস দিয়ে শুরু হয়, তবে ডেটা পরিচালনার পাশাপাশি কর্মপ্রবাহের অনুমতি দেওয়ার জন্য নির্বিচারে কোড সম্পাদনকে সমর্থন করার জন্য এটিকে প্রসারিত করে। তারা প্রোগ্রামারদের নিয়ন্ত্রণ দিয়ে এটি করে যাতে তারা নিয়মিত কোড ব্লকের জন্য মিউটেশন, লেনদেন এবং অদম্যতা সম্পর্কে সুস্পষ্ট সিদ্ধান্ত নিতে পারে — মূলত সরাসরি OLTP শব্দার্থবিদ্যা প্রকাশ করে। প্রোগ্রামার ব্যবসায়িক যুক্তি এবং ব্যবসার ডেটা অ্যাপ্লিকেশন অবস্থা থেকে আলাদা রাখার জন্য দায়ী। 

প্রকৃতপক্ষে, বিশুদ্ধ ডাটাবেস ভিউ হল যে অ্যাপ্লিকেশন অবস্থা সর্বদা ব্যবসায়িক ডেটা থেকে প্রাপ্ত করা যেতে পারে। এটি সাধারণত অ্যাপ্লিকেশন স্টেটকে লেনদেনের একটি সেট হিসাবে সংরক্ষণ করে করা হয় যা ডাটাবেসে ব্যবসার ডেটা পরিবর্তন করে। এটিকে একটি ডাটাবেস হিসাবে ভাবা সহজ যেটি উপরে বর্ণিত ওয়ার্কফ্লো সিস্টেমগুলির মতো একই শক্তিশালী গ্যারান্টি সহ কোডের ব্লকগুলি কার্যকর করতে পারে। 

অভ্যন্তরীণভাবে, আমরা এই কল অ্যাপ্লিকেশন লজিক লেনদেন প্ল্যাটফর্ম (ALTP) পন্থা কারণ, শেষ পর্যন্ত, এটি অ্যাপ্লিকেশনে OLTP লেনদেন প্রসারিত করে। কিন্তু প্রকৃতপক্ষে ALTP-এর বৈশিষ্ট্য হল, গ্রীনফিল্ড অ্যাপের জন্য, এটি অ্যাপ ডেভেলপারদের সরাসরি ব্যাক-এন্ড অবকাঠামো পরিচালনা করার প্রয়োজনীয়তাকে সম্পূর্ণরূপে পরিহার করতে পারে।  

ALTP লেন্স থেকে, সবচেয়ে বেশি ব্যবহৃত পদ্ধতিটি Firebase দিয়ে শুরু হয়েছে, যা একটি অফার করে পূর্ণ-পরিষেবা "ব্যাক-এন্ড অভিজ্ঞতা," প্রমাণীকরণ, ডেটা স্টোর, ডেটাবেস এবং আরও অনেক কিছু সহ। ফায়ারবেস এবং আরও সাম্প্রতিক প্রবেশকারী, যেমন সুপাবেস, গ্রিনফিল্ড প্রকল্পগুলির জন্য খুব জনপ্রিয় প্ল্যাটফর্ম রয়েছে। এবং যখন তারা তাদের OLTP শিকড়ের প্রতি বিশ্বস্ত থাকার প্রবণতা রাখে — এবং তাই লেনদেনমূলক ব্যাক-এন্ড ফাংশনগুলির জন্য নির্বিচারে কোড সম্পাদনকে সমর্থন করে না — সুপাবেস ইতিমধ্যে ওয়ার্কফ্লোগুলির জন্য সমর্থন যোগ করতে শুরু করেছে।

যাহোক, পরবর্তী প্রজন্মের ALTP অফার উত্তল মত ডাটাবেসের পাশাপাশি একটি লেনদেন হিসাবে নির্বিচারে কোড কার্যকর করার অনুমতি দেয়। এই অফারগুলি একটি সাধারণ ভাষায় (যেমন জাভাস্ক্রিপ্ট/টাইপস্ক্রিপ্ট) সম্পূর্ণরূপে লেনদেনের সাথে সঙ্গতিপূর্ণ কোড লেখার অনুমতি দেয়, যেখানে কোডের একক ব্লক ডেটা পড়তে, লিখতে এবং পরিবর্তন করতে পারে — উভয়ই অ্যাপ্লিকেশন স্টেট এবং ব্যবসায়িক ডেটা। এক অর্থে, এটি বিকাশকারীদের সত্যের একটি একক অনুসন্ধানযোগ্য উত্স দেয় এবং সাবস্ক্রিপশনের মতো ওয়ার্কফ্লো আদিম প্রদান করে। 

ALTP ওয়ার্কফ্লো ইঞ্জিনের ডাটাবেস থেকে ডিকপল হওয়ার সমস্যা সমাধান করে, কিন্তু, ফলস্বরূপ, সুবিধা পাওয়ার জন্য ব্যবহারকারীদের একটি স্ট্যান্ডার্ড OLTP-এর পরিবর্তে তাদের ডাটাবেস অফারিংয়ের উপর নির্ভর করতে হবে। ফলস্বরূপ, আমরা প্রাথমিকভাবে দলগুলিকে বিদ্যমান, জটিল ব্যাকএন্ডে একীভূত করার পরিবর্তে গ্রিনফিল্ড অ্যাপগুলির জন্য ALTP গ্রহণ করতে দেখি৷

উপরের চিত্রটি অনেক অপারেটরের সাথে আমরা কথা বলেছি তাদের একটি সংমিশ্রণ। কেউ কেউ শুধু একটি ওয়ার্কফ্লো ইঞ্জিন ব্যবহার করবে। কিছু শুধু একটি ডাটাবেস-কেন্দ্রিক পদ্ধতি ব্যবহার করবে। কিন্তু অনেকেই উভয়ই ব্যবহার করবে — বিশেষ করে যখন তারা সবেমাত্র কর্মপ্রবাহ গ্রহণ করতে শুরু করে। ওয়ার্কফ্লো ইঞ্জিনের ব্যবহারকারীরা আজ বৃহৎ, জটিল অ্যাপ্লিকেশনগুলির সাথে কাজ করে এমন ব্যাক-এন্ড দল হতে থাকে, যদিও আমরা অনেক ফুল-স্ট্যাক টিমকে সেগুলি গ্রহণ করতে দেখেছি। ব্যাক-এন্ড-এ-এ-সার্ভিস সমাধানগুলি আরও বেশি অ্যাপ্লিকেশন-ডেভেলপার-বান্ধব হতে থাকে এবং অ্যাপটি যখন প্রযুক্তি নির্বাচন পরিচালনা করে তখন বেশি ব্যবহৃত হয়। 

কনভারজেন্স

এটা স্পষ্ট হয়ে উঠছে যে ওয়ার্কফ্লো-কেন্দ্রিক পন্থা এবং ডাটাবেস-কেন্দ্রিক পদ্ধতিগুলি সংঘর্ষের পথে রয়েছে। এর প্রাথমিক কারণ হল অ্যাপ্লিকেশন স্টেট এবং ডাটাবেস স্টেট যৌক্তিকভাবে স্বতন্ত্র হলেও, তারা একে অপরের উপর নির্ভরশীল, এবং একটি সিস্টেম যা উভয়কে কভার করে না সঠিক হওয়া এবং ডিবাগ করা জটিল।  

উদাহরণ স্বরূপ, একজন ব্যবহারকারীর চেকআউট প্রক্রিয়ার জন্য স্টেট মেশিন ট্র্যাক করতে ব্যবহৃত একটি ওয়ার্কফ্লো ইঞ্জিন বিবেচনা করুন এবং সেই ব্যবহারকারী একটি কার্টে একটি আইটেম যোগ করছেন। সাধারণত, ওয়ার্কফ্লো ইঞ্জিনগুলি নিশ্চিত করে যে কোনও ব্যর্থতার ক্ষেত্রেও একটি কোড পদক্ষেপ চলবে। যাইহোক, এমন দৃষ্টান্ত হতে পারে যেখানে ইঞ্জিনকে একটি ব্যর্থতার সময় একটি প্রদত্ত পদক্ষেপ পুনরায় চালানোর প্রয়োজন কারণ এটি সম্পূর্ণরূপে নিশ্চিত নয় যে পদক্ষেপটি সম্পূর্ণভাবে সম্পন্ন হয়েছে কিনা। যদি এই পদক্ষেপটি একটি ঐতিহ্যগত ডাটাবেসে ব্যবসার ডেটা লেখার সাথে জড়িত থাকে (এই ক্ষেত্রে, কার্টের আইটেম) এবং ডাটাবেস ডুপ্লিকেট পুনঃপ্রচার সম্পর্কে সচেতন না হয়, এটি একটি ডুপ্লিকেট এন্ট্রির সাথে শেষ হবে৷ 

এই মোকাবেলা করার দুটি উপায় আছে. একটি উপায় হল সমস্যাটিকে অ্যাপ্লিকেশন ডেভেলপারের কাছে ঠেলে দেওয়া, যেটি শুধুমাত্র একটি আইটেম লেখা হয়েছে তা নিশ্চিত করতে ওয়ার্কফ্লো সিস্টেম দ্বারা প্রদত্ত ননস ব্যবহার করবে। কিন্তু এটি অনুমান করে যে বিকাশকারী অদম্যতা বোঝেন, যা সঠিকভাবে পেতে কুখ্যাতভাবে চতুর, এবং এটি একটি ওয়ার্কফ্লো সিস্টেম থাকার অনেক জাদুকে এড়িয়ে যায়। অন্য উপায় হল ওয়ার্কফ্লো ইঞ্জিনকে একটি ডাটাবেসের সাথে বেঁধে রাখা যা ওয়ার্কফ্লো লেনদেনের শব্দার্থবিদ্যা সম্পর্কে সচেতন। এটি এখনও ঘটেনি, তবে এটি বিশ্বাস করা কঠিন নয়। 

অন্যদিকে, ডাটাবেস-কেন্দ্রিক পদ্ধতিগুলি উপলব্ধি করে যে সাধারণ কর্মপ্রবাহ অ্যাপ্লিকেশন বিকাশকারীদের জন্য সত্যিই দরকারী। এবং তাই আমরা ডাটাবেস দেখতে শুরু করছি (যেমন উত্তল) — যা প্রথাগত ডাটাবেস ফাংশনকে সমর্থন করে যেমন প্রশ্ন, মিউটেশন, সূচী ইত্যাদি — সময়সূচী এবং সদস্যতার মতো কার্যকারিতা বাস্তবায়ন করে। এগুলি তাদের ওয়ার্কফ্লো ইঞ্জিন হিসাবে ব্যবহার করার অনুমতি দেয়। অর্থাৎ, তারা দৃঢ় গ্যারান্টি সহ নির্বিচারে কোড ব্লকগুলি কার্যকর করার অনুমতি দেয়। 

ইয়ান লিভিংস্টোন (যিনি এই অংশে প্রতিক্রিয়া দিয়েছেন) এটি বলেছেন, "এটি ক্লাসিক 'আপনি কি অ্যাপ্লিকেশন লজিককে ডাটাবেসে আনেন, নাকি ডাটাবেসকে অ্যাপ্লিকেশন লজিকে আনেন?' আবার খেলা… এইবার মনোলিথ ভেঙ্গে নিয়ে আসা হয়েছে।" কয়েক দশক ধরে এই দ্বিধাবিভক্তি থাকার পরে, এটি স্পষ্ট যে উভয় মডেলই স্বল্পমেয়াদে বজায় থাকবে। এটা অনেক কম স্পষ্ট যে দীর্ঘমেয়াদী ক্ষেত্রে থাকবে. 

চার্লি পলি (ডেফার), ড্যান ফ্যারেলি (ইনগেস্ট), ডেভিড খুরশিদ (স্টেটলি), ইয়ান লিভিংস্টোন (কেপ সিকিউরিটি), এনেস আকর (আপস্ট্যাশ), জেমস কাউলিং (উত্তল), জেমি টার্নার (উত্তল), পল কোপলেস্টোন (সুপাবেস) কে বিশেষ ধন্যবাদ। ), স্যাম ল্যামবার্ট (প্ল্যানেটস্কেল), টনি হোল্ডস্টক-ব্রাউন (ইনজেস্ট), ম্যাট আইটকেন (ট্রিগার) এই পোস্টটি পর্যালোচনা এবং প্রতিক্রিয়া দেওয়ার জন্য। উপরন্তু, আমাদের সাহায্য করার জন্য বেঞ্জামিন হিন্ডম্যান (রিবুট), ফ্রেডরিক বজর্ক (গ্রাফবেস), গ্লাবার কোস্টা (চিসেলস্ট্রাইক), গুইলাম সেলেস (লাইভব্লক), ম্যাক্সিম ফাতেভ (টেম্পোরাল), স্টিভেন ফ্যাব্রে (লাইভব্লকস) এবং বীরেন বারাইয়া (অর্কস) কে ধন্যবাদ গবেষণা.

• এসইও চালিত বিষয়বস্তু এবং পিআর বিতরণ। আজই পরিবর্ধিত পান।
• প্লেটোব্লকচেন। Web3 মেটাভার্স ইন্টেলিজেন্স। জ্ঞান প্রসারিত. এখানে প্রবেশ করুন.
• অ্যাড্রিয়েন অ্যাশলির সাথে ভবিষ্যত মিন্টিং। এখানে প্রবেশ করুন.
• উত্স: https://a16z.com/2023/04/14/the-modern-transactional-stack/