প্রতিটি ইঞ্জিনিয়ারিং টিম এমন একটি সিস্টেম চায় যা কোনো সমস্যা ছাড়াই মসৃণভাবে বৃদ্ধি পায়। আমরা কল্পনা করি ট্রাফিক মসৃণভাবে বাড়ছে, সার্ভারগুলো সচল আছে এবং রাজস্ব ক্রমাগত বৃদ্ধি পাচ্ছে। তারপর বাস্তবতার মুখোমুখি হতে হয়। একটি ভাইরাল মার্কেটিং ক্যাম্পেইন ব্যবহারকারীদের ঢেউ নিয়ে আসে, ডেটাবেস লক হয়ে যায় এবং রাত তিনটের সময় কেউ একজন পাগলের মতো সার্ভিসগুলো রিস্টার্ট করতে থাকে। তখন আমাদের স্বাভাবিক প্রতিক্রিয়া হয় টুলগুলোর ওপর দোষ চাপানো। আমরা নিজেদের বলি যে আমাদের আরও বেশি কোর, দ্রুততর ডিস্ক বা অন্য কোনো ক্যাশিং লেয়ার প্রয়োজন ছিল। কিন্তু বৃদ্ধি হার্ডওয়্যার থেকে আসে না। এটি আসে গঠন বা স্ট্রাকচার থেকে। যদি আপনার ভিত্তি বা ফাউন্ডেশন ওজন বণ্টন করতে না পারে, তবে প্রতিটি নতুন ব্যবহারকারী জয়ের বদলে একটি বোঝা হয়ে দাঁড়াবে।
কেন টুলস একটি ত্রুটিপূর্ণ ভিত্তিকে রক্ষা করতে পারে না
আপনি শত শত ক্লাউড ইনস্ট্যান্স চালু করতে পারেন, বিভিন্ন ভৌগোলিক অঞ্চলের মধ্যে লোড ব্যালেন্সার যোগ করতে পারেন এবং একটি গ্লোবাল কন্টেন্ট ডেলিভারি নেটওয়ার্কের মাধ্যমে প্রতিটি স্ট্যাটিক অ্যাসেট ক্যাশ করতে পারেন। এগুলো হলো ক্ষমতা বৃদ্ধিকারক (force multipliers)। তবুও, শূন্যকে গুণ করলেও ফলাফল শূন্যই থাকে। একটি জটিল ডিপেন্ডেন্সিযুক্ত মনোলিথিক অ্যাপ্লিকেশন তার নিচে যত বেশি হার্ডওয়্যারই থাকুক না কেন, নিজের ভারেই শ্বাসরোধ হয়ে মারা যাবে।
একটি অনলাইন স্টোরের কথা কল্পনা করুন যেখানে প্রোডাক্ট ক্যাটালগ, পেমেন্ট প্রসেসিং এবং ইউজার অথেন্টিকেশন—সবই একটি সিঙ্গেল কোডবেসে থাকে। যখন চেকআউট ফ্লো ধীর হয়ে যায়, তখন পুরো সাইটটি ধীরগতির হয়ে পড়ে। লগইন পেজ আটকে যায়। ব্রাউজিং অভিজ্ঞতা ক্ষতিগ্রস্ত হয়। আপনি বাকি সবকিছু স্কেল না করে শুধুমাত্র বটলনেক অংশটি স্কেল করতে পারবেন না। এটি অত্যন্ত ব্যয়বহুল, অদক্ষ এবং ভঙ্গুর। আপনি এমন কম্পিউট পাওয়ারের জন্য অর্থ প্রদান করতে থাকেন যা কারো উপকারে আসে না, আর আপনার ব্যবহারকারীরা সেই পেজগুলোর জন্য অপেক্ষা করতে থাকে যা তাৎক্ষণিকভাবে লোড হওয়ার কথা ছিল।
আর্কিটেকচার হলো এই ফাঁদ থেকে বাঁচার সমাধান। এটি হলো সেই অদৃশ্য কঙ্কাল যা নির্ধারণ করে আপনার টুলগুলো আপনাকে সাহায্য করবে নাকি ক্ষতি করবে।
একটি মজবুত আর্কিটেকচারের প্রকৃত অর্থ কী
একটি মজবুত আর্কিটেকচার হলো মূলত একটি পরিকল্পনা যে কোন দায়িত্ব কোথায় থাকবে। এটি শুরুতেই কিছু অস্বস্তিকর প্রশ্ন উত্থাপন করে। একটি অংশ ভেঙে পড়লে কী হবে? রেকমেন্ডেশন ইঞ্জিন স্পর্শ না করেই কি আপনি বিলিং লজিক পরিবর্তন করতে পারবেন? আপনার অ্যাপ্লিকেশনের এক কোণে ট্রাফিকের হঠাৎ বৃদ্ধি কি সিস্টেমের বাকি অংশকে স্বাভাবিকভাবে চলতে বাধা দেবে? এই প্রশ্নগুলো আপনার প্রোগ্রামিং ল্যাঙ্গুয়েজ, ফ্রেমওয়ার্ক বা ক্লাউড প্রোভাইডারের পছন্দের চেয়ে অনেক বেশি গুরুত্বপূর্ণ।
ভালো আর্কিটেকচার আপনাকে সিদ্ধান্ত পরিবর্তনের সুযোগ দেয়। এটি স্পষ্ট সীমানা নির্ধারণ করে যাতে একটি টিমের পরীক্ষা-নিরীক্ষা অন্য টিমের প্রোডাকশন ওয়ার্কলোডকে অস্থিতিশীল করে না তোলে। এটি ব্যর্থতাকে কোনো আকস্মিক ঘটনা হিসেবে না দেখে একটি স্বাভাবিক অপারেটিং কন্ডিশন হিসেবে বিবেচনা করে। যখন আপনি ব্যর্থতার কথা মাথায় রেখে ডিজাইন করেন, তখন আপনি আর কাঁচের ঘর তৈরি করেন না, বরং এমন কাঠামো তৈরি করতে শুরু করেন যা প্রয়োজনে নমনীয় হতে পারে।
একটি ব্যবহারিক প্যাটার্ন হিসেবে মাইক্রোসার্ভিসেস
এই ধরনের কাঠামো অর্জনের একটি ব্যবহারিক উপায় হলো আপনার অ্যাপ্লিকেশনকে মাইক্রোসার্ভিসেস-এ বিভক্ত করা। একটি বিশাল কোডবেসের পরিবর্তে, আপনি অ্যাপটিকে ছোট ছোট অংশে ভাগ করবেন। প্রতিটি অংশ একটি নির্দিষ্ট কাজ সম্পন্ন করে। পেমেন্ট সার্ভিস লেনদেন সম্পন্ন করে। ইনভেন্টরি সার্ভিস স্টক ট্র্যাক করে। নোটিফিকেশন সার্ভিস ইমেল এবং টেক্সট মেসেজ পাঠায়। তারা সরাসরি মেমরি অ্যাক্সেস বা শেয়ার্ড ডেটাবেস টেবিলের পরিবর্তে নির্ধারিত ইন্টারফেসের মাধ্যমে যোগাযোগ করে।
এই বিভাজন প্রযুক্তিগত এবং সাংগঠনিক উভয় ক্ষেত্রেই কাজ করার প্রকৃত সুযোগ তৈরি করে।
পুরো সিস্টেম নষ্ট না করে ছোট ছোট অংশ আপডেট করা
যখন সার্ভিসগুলো ছোট এবং নির্দিষ্ট কাজের জন্য তৈরি হয়, তখন আপনি ক্যাসকেড ফেইলিউরের ঝুঁকি ছাড়াই একটি অংশ প্যাচ করতে পারেন। যদি আপনার টিম শিপিং ক্যালকুলেশন অ্যালগরিদমে কোনো বাগ খুঁজে পায়, তবে আপনি শুধুমাত্র সেই সার্ভিসটি ঠিক করবেন এবং আলাদাভাবে ডেপ্লয় করবেন। অ্যাপ্লিকেশনের বাকি অংশ চলতে থাকবে। ব্যবহারকারীরা তখনও প্রোডাক্ট ব্রাউজ করতে পারবেন, লগইন করতে পারবেন এবং কার্টে আইটেম যোগ করতে পারবেন। যেকোনো একক পরিবর্তনের ক্ষতির পরিধি (blast radius) অত্যন্ত ক্ষুদ্র থাকে। এর বিপরীতে একটি মনোলিথিক সিস্টেমের কথা ভাবুন, যেখানে একটি হেল্পার ফাংশনে একটি টাইপো চেকআউট, রেজিস্ট্রেশন এবং রিপোর্টিং—সবকিছু একসাথে ভেঙে ফেলতে পারে।
ট্রাফিক বাড়লে নির্দিষ্ট ফাংশন স্কেল করা
একটি অ্যাপ্লিকেশনের সব অংশে ট্রাফিক কখনোই সমান থাকে না। একটি ফ্ল্যাশ সেলের সময় আপনার অর্ডার পাইপলাইন চাপে পড়তে পারে, অথচ আপনার কন্টেন্ট ম্যানেজমেন্ট সিস্টেম প্রায় অলস বসে থাকতে পারে। একটি টাইটলি কাপলড সিস্টেমে আপনাকে হয় সবকিছু স্কেল করতে হবে অথবা কিছুই না। মাইক্রোসার্ভিসেসের মাধ্যমে আপনি আপনার রিসোর্সগুলোকে সুনির্দিষ্টভাবে ব্যবহার করতে পারেন। চেকআউট সার্ভিসের আরও বেশি ইনস্ট্যান্স চালু করুন। প্রোডাক্ট ক্যাটালগকে তার স্বাভাবিক ক্ষমতায় চলতে দিন। একটি প্রোডাক্ট লঞ্চের সময়, আপনার ইমেজ প্রসেসিং ওয়ার্কার্স হাজার হাজার থাম্বনেইল তৈরি করতে পারে, অথচ আপনার সার্চ ইনডেক্স শান্ত থাকতে পারে। ইমেজ ওয়ার্কারদের চাহিদা মেটানোর জন্য সার্চ ক্লাস্টার বড় করার কোনো প্রয়োজন নেই। আপনি সেখানেই অর্থ ব্যয় করেন যেখানে ব্যবহারকারীরা তা অনুভব করে, এবং আপনার সিস্টেম চাপের মধ্যেও রেসপন্সিভ থাকে।
দীর্ঘ ডাউনটাইম ছাড়াই নতুন কোড ডেপ্লয় করা
ছোট সার্ভিস এমন সব ডেপ্লয়মেন্ট প্যাটার্ন ব্যবহারের সুযোগ দেয় যা মেইনটেন্যান্স উইন্ডোকে অপ্রয়োজনীয় করে তোলে। আপনি রোলিং ডেপ্লয়মেন্ট (rolling deployments) ব্যবহার করতে পারেন, যেখানে বাকি অংশ ট্রাফিক সার্ভিস দেওয়া চালিয়ে যাবে এবং আপনি একটি নির্দিষ্ট অংশের ইনস্ট্যান্সে নতুন কোড পুশ করবেন। আপনার এরর রেট (error rate) পর্যবেক্ষণ করুন, এবং যদি কিছু ভুল মনে হয়, তবে কয়েক সেকেন্ডের মধ্যেই রিকোয়েস্টগুলো আগের ভার্সনে ফিরিয়ে নিয়ে যান। ব্লু-গ্রিন ডেপ্লয়মেন্ট (Blue-green deployments) আপনাকে একটি সম্পূর্ণ নতুন এনভায়রনমেন্ট তৈরি করতে, সেটি যাচাই করতে এবং ন্যূনতম ঝুঁকিতে ট্রাফিক সেখানে সরিয়ে নিতে সাহায্য করে। ডেটাবেস মাইগ্রেশন (database migrations) হাতে করার জন্য সিস্টেমকে ঘণ্টার পর ঘণ্টা বন্ধ রাখার প্রয়োজন হয় না।
দ্রুত নতুন ফিচার তৈরি করুন
বিশাল কোডবেস সতর্কতার জন্ম দেয়। একটি মাত্র পরিবর্তনের জন্য হাজার হাজার অপ্রাসঙ্গিক লজিক বোঝা, ঘণ্টার পর ঘণ্টা ধরে চলা রিগ্রেশন টেস্ট এবং রকেট লঞ্চের মতো জটিল ডেপ্লয়মেন্ট শিডিউল মেনে চলতে হয়। ছোট সার্ভিস এই ভয় দূর করে। একটি টিম তাদের পরিচিত একটি সার্ভিসের মাত্র কয়েকশ লাইন পরিবর্তন করে নতুন ফিচার তৈরি করতে পারে। তারা একই দিনে কমিট, টেস্ট এবং শিপ করতে পারে। এই গতি বহুগুণ বৃদ্ধি পায়। যখন সার্ভিসগুলো সুনির্দিষ্ট দায়িত্ব দ্বারা সীমাবদ্ধ থাকে, তখন টিমগুলো একে অপরের কাজে বাধা দেয় না। তারা তাদের ডোমেইনের ওপর শুরু থেকে শেষ পর্যন্ত পূর্ণ নিয়ন্ত্রণ রাখে।
স্বাধীনতা বড় ধরনের বিপর্যয় রোধ করে
প্রতিটি সার্ভিস নিজস্বভাবে কাজ করে। এই স্বাধীনতা কেবল সাংগঠনিক সুবিধার জন্য নয়; এটি একটি কাঠামোগত সুরক্ষা। যদি রেকমেন্ডেশন ইঞ্জিন (recommendation engine) ডাউন হয়ে যায়, তবুও স্টোরটি পণ্য বিক্রি করা চালিয়ে যেতে সক্ষম হওয়া উচিত। যদি অ্যানালিটিক্স পাইপলাইন (analytics pipeline) কোনো ত্রুটিপূর্ণ ইভেন্টের কারণে আটকে যায়, তবে লগইন সার্ভিসটি যেন ব্যবহারকারীদের অথেন্টিকেট করতে পারে। আপনি সার্ভিসগুলোর মধ্যে সার্কিট ব্রেকার (circuit breakers) এবং ফলব্যাক পাথ (fallback paths) ডিজাইন করেন যাতে একটি ব্যর্থতা পুরো সিস্টেমকে অচল করে না দেয়। সিস্টেমটি আপনার ব্যবহারকারীদের সাথে সাথে বৃদ্ধি পায় কারণ এটি ভেঙে না পড়ে চাপ সহ্য করতে পারে।
একটি সতর্কবার্তা: অন্ধভাবে বিভক্ত করবেন না
এর মানে এই নয় যে আপনি প্রথম দিনেই আপনার কোডবেসকে খণ্ড খণ্ড করে ফেলবেন। মাইক্রোসার্ভিসের জন্য সুনির্দিষ্ট সীমানা প্রয়োজন। যদি আপনার টিমগুলো না জানে যে একটি ডোমেইন কোথায় শেষ হচ্ছে এবং অন্যটি কোথায় শুরু হচ্ছে, তবে তারা একটি ডিস্ট্রিবিউটেড সিস্টেমের পরিবর্তে একটি ডিস্ট্রিবিউটেড বিশৃঙ্খলা (distributed mess) তৈরি করবে। আপনি কোডের জটিলতার বদলে অপারেশনাল জটিলতা সামলাতে শুরু করবেন এবং হঠাৎ করেই নেটওয়ার্ক ল্যাটেন্সি (network latency), ডিস্ট্রিবিউটেড ট্রানজ্যাকশন (distributed transactions), রিট্রাই স্টর্ম (retry storms) এবং ডজন ডজন লগ স্ট্রিমের মাধ্যমে অবজারভেবিলিটি (observability) ম্যানেজ করতে হিমশিম খাবেন। একটি ধীরগতির চেকআউট ডিবাগ করার অর্থ হতে পারে চারটি নেটওয়ার্ক হপ এবং তিনটি ভিন্ন ডেটা স্টোরের মধ্য দিয়ে একটি একক রিকোয়েস্ট ট্র্যাক করা।
যদি আপনার টিম এই বাড়তি চাপের জন্য প্রস্তুত না থাকে, তবে প্রতিকারের চেয়ে রোগটিই বেশি কষ্টদায়ক হবে। কখনও কখনও মডুলার মনোলিথ (modular monolith) দিয়ে শুরু করা বুদ্ধিমানের কাজ। কোডবেসের ভেতরে পেমেন্ট লজিক এবং ইনভেন্টরি লজিক আলাদা রাখুন, এমনকি যদি তারা একসাথে ডেপ্লয়ও হয়। ইন্টারনাল এপিআই (internal APIs) এবং একই ইঞ্জিনের মধ্যে আলাদা ডেটাবেস স্কিমা ব্যবহার করে সীমানা বজায় রাখুন। যখন সেই সীমানাগুলো স্থিতিশীল প্রমাণিত হবে এবং ট্রাফিক প্যাটার্ন সেই বাড়তি কাজের বোঝা বহন করার মতো হবে, তখন একটি সার্ভিস আলাদা করুন। আর্কিটেকচার হওয়া উচিত কিছু সুপরিকল্পিত দরজার সমষ্টি, রাতারাতি তৈরি করা কোনো দেয়াল নয় যা আপনি কেবল একটি ব্লগ পোস্ট পড়ে তৈরি করেছেন।
উদ্দেশ্য নিয়ে শুরু করুন
সুসংহত আর্কিটেকচার মানে পাঁচ বছর পরের ট্রাফিক সম্পর্কে ভবিষ্যদ্বাণী করা নয়। এটি হলো নিজেকে বিকল্প বা অপশন দিয়ে রাখা। আপনার ওয়েব অ্যাপ বড় করার জন্য আপনি কেবল টুলের ওপর নির্ভর করতে পারেন না, তবে চাপ বাড়ার আগেই আপনি বুদ্ধিমত্তার সাথে সমস্যা থেকে বেরিয়ে আসার পথ খুঁজে নিতে পারেন। দায়িত্বের মধ্যকার সীমানা বজায় রাখুন। ছোট এবং সুনির্দিষ্ট অংশ তৈরি করুন যা তাদের নিজস্ব কাজ নিজেরাই পরিচালনা করতে পারে। টিমগুলোকে পুরো সিস্টেম নষ্ট না করে দ্রুত কাজ করার স্বায়ত্তশাসন দিন। যখন আপনি একটি সুসংহত আর্কিটেকচার দিয়ে শুরু করবেন, তখন আপনি পরবর্তীতে সময় এবং শ্রম সাশ্রয় করবেন কারণ সাইট যখন বিপর্যয়ের মুখে থাকবে তখন আপনাকে আর কোর লজিক নতুন করে লিখতে হবে না।
আসল শিক্ষা
স্কেলেবিলিটি (Scalability) এমন কোনো ফিচার নয় যা প্রবৃদ্ধি আসার পর আপনি যুক্ত করবেন। এটি হলো আপনার সিস্টেমের দায়িত্ব কীভাবে প্রবাহিত হবে সে সম্পর্কে আপনি শুরুতে যে সিদ্ধান্তগুলো নিয়েছিলেন তার একটি স্বাভাবিক ফলাফল। সঠিক সীমানা বেছে নিন। ব্যর্থতাকে বিচ্ছিন্ন করুন। যা সমস্যা করছে তা স্কেল করুন, আর যা ঠিকঠাক চলছে তাকে যেমন আছে তেমন থাকতে দিন। এটি করতে পারলে, পরবর্তীতে আপনি যে টুলগুলো যোগ করবেন সেগুলো আসলে একটি মজবুত ভিত্তির ওপর কাজ করতে পারবে।