আপনার স্কেলেবল ব্যাকএন্ড কি একটি ঘড়ির কাঁটা ধরে থাকা টাইম বোম্ব?
অনেক ডেভেলপার মনে করেন স্কেলিং মানে হলো আরও বেশি সার্ভার যোগ করা। তারা আরও বেশি ব্যবহারকারী সামলানোর জন্য ক্লাউড-নেটিভ টুলস এবং ডিস্ট্রিবিউটেড ডাটাবেস ব্যবহার করেন। কিন্তু এটি প্রায়শই একটি নতুন সমস্যার সৃষ্টি করে। আপনি কোনো দুর্গ তৈরি করছেন না; আপনি তাসের ঘর তৈরি করছেন।
পরিকল্পনা ছাড়া হরাইজন্টালি স্কেলিং করা কেবল আপনার ফেইলর ডোমেইনগুলোকে (failure domains) আরও বাড়িয়ে দেয়। যদি আপনার সিস্টেমে ফল্ট টলারেন্স (fault tolerance) না থাকে, তবে একটি ছোট ভুল সবকিছু ধসিয়ে দিতে পারে।
একটি প্রকৃত সিস্টেম তৈরি করতে আপনাকে দুটি বিষয়ের ওপর গুরুত্ব দিতে হবে:
১. ফল্ট টলারেন্স (Fault Tolerance) আরও বেশি ইন্সট্যান্স যোগ করা কোরিলেটেড ফেইলর (correlated failures) প্রতিরোধ করে না। আপনাকে ফেইলরগুলোকে আলাদা (isolate) করতে হবে যাতে সেগুলো ছড়িয়ে না পড়ে।
- একাধিক Availability Zone ব্যবহার করুন।
- দুটি বড় ইন্সট্যান্স ব্যবহার করার পরিবর্তে ছোট ছোট সার্ভিস ইন্সট্যান্স ছড়িয়ে দিন।
- Raft বা Paxos-এর মতো quorum-based consensus ব্যবহার করুন। এটি split-brain পরিস্থিতি প্রতিরোধ করে যেখানে দুটি রিজিয়ন নিজেদের লিডার মনে করে।
- নেটওয়ার্ক স্প্লিটের সময় ত্রুটিপূর্ণ রিজিয়নগুলোকে বন্ধ করতে fencing mechanism ব্যবহার করুন।
২. ডাটা কনসিস্টেন্সি (Data Consistency) ইভেনচুয়াল কনসিস্টেন্সি (Eventual consistency) গতির জন্য চমৎকার। কিন্তু এটি ক্রিটিক্যাল বিজনেস লজিকের জন্য অত্যন্ত ক্ষতিকর। পেমেন্ট বা অ্যাকাউন্টের ব্যালেন্সের জন্য আপনার প্রয়োজন স্ট্রং কনসিস্টেন্সি (strong consistency)।
- ডিস্ট্রিবিউটেড ট্রানজ্যাকশনের ওপর নির্ভর করবেন না যা আপনার সিস্টেমকে ধীর করে দেয়।
- Transactional Outbox Pattern ব্যবহার করুন।
- আপনার মূল ডাটা এবং একটি "outbox" টাস্ক একটি মাত্র ট্রানজ্যাকশনের মাধ্যমে আপনার লোকাল ডাটাবেসে লিখুন।
- সেই টাস্কগুলোকে একটি মেসেজ কিউতে (message queue) পাঠানোর জন্য একটি relayer ব্যবহার করুন।
- আপনার ডাউনস্ট্রিম সার্ভিসগুলো যেন idempotent হয় তা নিশ্চিত করুন, যাতে তারা নিরাপদে ডুপ্লিকেট মেসেজ হ্যান্ডেল করতে পারে।
প্রকৃত স্কেলেবিলিটি হলো রেজিলিয়েন্স (resilience) বা সহনশীলতা নিয়ে। আপনি যদি এই নীতিগুলো উপেক্ষা করেন, তবে আপনি কেবল ব্যর্থতার জন্য একটি বড় খেলার মাঠ তৈরি করছেন। আজই সবচেয়ে খারাপ পরিস্থিতির (worst-case scenario) কথা মাথায় রেখে ডিজাইন করুন।
উৎস: https://dev.to/prabashanadev/is-your-scalable-backend-a-ticking-time-bomb-6o7