ব্যাকএন্ড এত জটিল কেন?

ভূমিকা

Backend শেখা নিয়ে আজকাল রিসোর্সের কোনো অভাব নেই। YouTube, Blog, Documentation, Online Course, কোনটা ছেড়ে কোনটা দেখবেন, সেটাই বরং বড় প্রশ্ন। নতুন কোনো Tool, Framework জনপ্রিয় হলে কয়েক দিনের মধ্যেই তার উপর অসংখ্য Tutorial, Course আর Article পাবলিশ হয়ে যায়। আগে যেখানে শেখার জন্য ভালো বই, কন্টেন্ট খুঁজে পাওয়াই কঠিন ছিল, এখন পরিস্থিতি ঠিক উল্টো। শেখার উপকরণের অভাব নেই, বরং এত বেশি যে কোথা থেকে শুরু করবেন, সেটাই বুঝে ওঠা কঠিন।

এত কিছু থাকার পরেও, Backend সিস্টেম কিভাবে কাজ করে এটা ভালোভাবে শেখা অনেকের কাছে এখনো বেশ জটিল মনে হয়। কেউ কেউ হয়তো Redis, Kafka, Load Balancer, CDN, Message Queue, এই নামগুলো শুনেছেন। কোনোটার উপর হয়তো কাজও করেছেন। কিন্তু সবগুলো একসাথে একটা System-এ কেন আছে, কিংবা কোন সমস্যার কারণে একটা নতুন Component এড করার প্রয়োজন হলো, বা কোনটা আমার সিস্টেমে ব্যবহারের দরকারই নাই, সেটা অনেক সময় পরিষ্কার থাকে না। বিশেষ করে যারা নতুন ব্যাকেন্ড শেখা শুরু করেন তাদের এত এত টুল, টার্মের চক্করে মাথা ঘোরা শুরু হয়।

এখানে আমার দৃষ্টিতে একটা বড় ধরনের স্ট্রাটেজিক মিস্টেক আছে বলে মনে হয়।

শেখার শুরুতেই আমরা সাধারণত Tool-এর দিকে চলে যাই। Redis কী, Docker কী, Kubernetes কী, Kafka কী, এভাবে একটার পর একটা Technology সম্পর্কে জানার চেষ্টা করি। এতে সমস্যা নেই। সমস্যা তখনই হয়, যখন Tool-টাই শেখার কেন্দ্রবিন্দু হয়ে যায়। কারণ বাস্তব Project-এ খুব কম ক্ষেত্রেই কেউ একটা নির্দিষ্ট Tool ব্যবহার করার সিদ্ধান্ত নিয়ে কাজ শুরু করে। বরং একটা সমস্যা সামনে আসে, তারপর সেই সমস্যার জন্য উপযুক্ত সমাধান খোঁজা হয়। সেই সমাধান হিসেবে হয়তো Redis আসে, হয়তো Queue আসে, আবার কখনো দেখা যায় কোনো নতুন Component-এর আদৌ দরকার নেই।

একজন অভিজ্ঞ Backend Engineer সাধারণত Tool দিয়ে চিন্তা করেন না। তিনি চিন্তা করেন সমস্যাটা নিয়ে। Database কেন স্লো হয়ে যাচ্ছে? User-কে এতক্ষণ অপেক্ষা করতে হচ্ছে কেন? একই Request বারবার Process করতে হচ্ছে কেন? এই প্রশ্নগুলোর উত্তর খুঁজতে গিয়েই একসময় Cache, Queue কিংবা Load Balancer-এর মতো Component-এর প্রয়োজন হয়।

এই বইটার উদ্দেশ্য আপনাকে Backend শেখানো না। সত্যি বলতে, ১৫–২০ মিনিটে সেটা সম্ভবও না। বরং আমি চেষ্টা করব এমন কিছু Mental Model নিয়ে আলোচনা করতে, যেগুলো Backend-কে অন্যভাবে দেখতে সাহায্য করবে। আমার বিশ্বাস, একবার এই দৃষ্টিভঙ্গিটা তৈরি হয়ে গেলে নতুন কোনো Tool শেখাও অনেক সহজ হয়ে যায়। কারণ তখন আপনি শুধু Tool শিখবেন না, বুঝতে পারবেন সেই Tool-টার প্রয়োজনই বা কেন হলো।

আরেকটা বিষয় শুরুতেই পরিষ্কার করে বলতে চাই। এই বইয়ে Redis-এর Command, Docker-এর Configuration কিংবা Kubernetes Cluster Setup নিয়ে বিস্তারিত আলোচনা থাকবে না। ইচ্ছা করেই থাকবে না। এগুলোর প্রতিটাই আলাদা করে শেখার মতো বড় বিষয়। এই বইয়ের উদ্দেশ্য তার চেয়ে একটু ভিন্ন। আমি চাই, পরেরবার যখন আপনি কোনো Architecture Diagram দেখবেন, তখন Box গোনা শুরু না করে প্রতিটা Component-কে একটা সমস্যার সমাধান হিসেবে দেখার চেষ্টা করবেন।

যদি এই লেখাটা পড়া শেষ করে আপনার Backend সম্পর্কে ভাবার ধরনে সামান্যও পরিবর্তন আসে, তাহলেই আমি মনে করব এই ছোট্ট প্রচেষ্টা সফল হয়েছে।

First Principle দিয়ে Backend শেখা

"First Principle" শব্দটা গত কয়েক বছরে বেশ জনপ্রিয় হয়েছে। বিশেষ করে Elon Musk বিভিন্ন Interview-তে এই বিষয়টা নিয়ে কথা বলার পর অনেকেই প্রথমবারের মতো শব্দটার সাথে পরিচিত হন। তবে ধারণাটা নতুন না। প্রায় আড়াই হাজার বছর আগে গ্রিক দার্শনিক Aristotle কোনো বিষয়কে বোঝার জন্য সেটাকে তার সবচেয়ে মৌলিক সত্য পর্যন্ত ভেঙে দেখার কথা বলেছিলেন। পরে সেখান থেকেই যুক্তি দিয়ে আবার পুরো বিষয়টা গড়ে তোলার চেষ্টা করা হয়। এটাই মূলত First Principle চিন্তার ভিত্তি।

শুনতে হয়তো একটু দার্শনিক মনে হচ্ছে। কিন্তু Software Engineering-এ আমরা প্রায়ই এই চিন্তাটাই ব্যবহার করি, অনেক সময় বুঝতেও পারি না।

ধরুন, আপনি Backend শেখা শুরু করেছেন। ইন্টারনেটে সার্চ করলেই অসংখ্য Roadmap পাবেন। কোথাও Redis আছে, কোথাও Docker, কোথাও Kubernetes, আবার কোথাও Message Queue। স্বাভাবিকভাবেই মনে হতে পারে, একজন ভালো Backend Engineer হতে হলে এই তালিকার সবকিছুই একে একে শিখতে হবে।

এই চিন্তায় খুব একটা ভুল নেই। কিন্তু একটা সমস্যা আছে।

এভাবে শিখতে গেলে আপনি Tool শিখবেন, কিন্তু Tool-এর প্রয়োজনটা সবসময় পরিষ্কার হবে না। কয়েক মাস পরে নতুন আরেকটা Technology এলে আবার নতুন করে শেখা শুরু করতে হবে। কারণ আগেরবারও আপনি Tool শিখেছিলেন, সমস্যাটা না।

একটা ছোট উদাহরণ দিই।

ধরুন, আমি আপনাকে জিজ্ঞেস করলাম, Redis কী?

আপনি হয়তো উত্তর দিলেন, "Redis হলো একটি In-memory Key-Value Database।"

তথ্য হিসেবে এটা ঠিক।

কিন্তু এই উত্তরটা একজন Beginner-কে খুব বেশি সাহায্য করে না। কারণ তার পরের প্রশ্ন হবে, "ঠিক আছে, কিন্তু Redis ব্যবহার করব কেন?"

এবার যদি First Principle দিয়ে চিন্তা করি, তাহলে প্রশ্নটাই বদলে যায়।

আমরা আর Redis কী, সেটা দিয়ে শুরু করি না। আমরা শুরু করি এই প্রশ্ন দিয়ে, কোন সমস্যার কারণে Redis-এর প্রয়োজন হলো?

এখন ধরুন, আপনার একটা ছোট E-commerce Application আছে। প্রতিদিন কয়েকশো User আসছে। Database খুব ভালোভাবেই সব Request সামলে নিচ্ছে। এই অবস্থায় Redis এড করার কোনো কারণ নেই। কারণ এখনো এমন কোনো সমস্যা তৈরি হয়নি, যেটার জন্য Redis দরকার।

কয়েক মাস পরে User সংখ্যা অনেক বেড়ে গেল। দেখা গেল একই Product Page হাজার হাজার মানুষ দেখছে, আর Database-কে একই Query বারবার Execute করতে হচ্ছে। তখন কেউ একটা প্রশ্ন করল, একই উত্তর যদি কিছু সময়ের জন্য Memory-তে রেখে দেওয়া যায়, তাহলে কি Database-এর উপর চাপ কমবে?

এই প্রশ্নের উত্তর খুঁজতে গিয়েই Cache-এর ধারণা আসে। Redis হলো সেই ধারণাকে বাস্তবায়ন করার একটি উপায়।

খেয়াল করুন, Redis দিয়ে গল্পটা শুরু হয়নি। গল্পটা শুরু হয়েছে একটা সমস্যা দিয়ে।

Backend-এর প্রায় সব Component-এর ক্ষেত্রেই একই বিষয় সত্যি।

• Queue এসেছে কারণ কিছু কাজ User-এর Request-এর সময় না করে পরে করা ভালো।
• CDN এসেছে কারণ পৃথিবীর এক প্রান্ত থেকে আরেক প্রান্তে Data পাঠাতে সময় লাগে।
• Load Balancer এসেছে কারণ একসময় একটা Server আর সব Request সামলাতে পারে না।

আমরা এই লেখার প্রতিটা বিষয়কে এই দৃষ্টিভঙ্গি থেকেই দেখব। কোন Tool কীভাবে Configure করতে হয়, সেটা নয়; বরং কোন সমস্যার কারণে সেটার প্রয়োজন হলো, সেটা বোঝার চেষ্টা করব। কারণ আমার অভিজ্ঞতায়, সমস্যা বুঝতে পারলে Tool শেখা অনেক সহজ হয়ে যায়। কিন্তু শুধু Tool শিখে সমস্যাটা বোঝা অনেক কঠিন।

মনে রাখুন

বড় System-এ নতুন নতুন Component এড করতেই হয়?

Backend নিয়ে যারা নতুন, তাদের অনেকের মধ্যেই একটা ধারণা কাজ করে।

বড় কোম্পানিগুলোর Architecture বুঝি শুরু থেকেই এমন ছিল। শুরুতেই Redis ছিল, Queue ছিল, Search Engine ছিল, Load Balancer ছিল। যেন এগুলো ছাড়া Backend বানানোই যায় না।

কিন্তু বাস্তবে বেশিরভাগ System-এর গল্প এমন না।

ধরুন, আপনি একটা ছোট E-commerce Application বানালেন। শুরুতে খুব বেশি User নেই। Product দেখানো যায়, Order করা যায়, Database-ও সুন্দরভাবে সব Request সামলে নিচ্ছে। এই অবস্থায় যদি কেউ আপনাকে বলে Redis এড করতে, খুব সম্ভবত আপনার প্রথম প্রশ্ন হবে, "কেন?"

এই প্রশ্নটাই গুরুত্বপূর্ণ।

কারণ শুধুমাত্র Redis ব্যবহার করার জন্য Redis এড করার কোনো অর্থ নেই।

Software Engineering-এ একটা বিষয় আমরা প্রায়ই ভুলে যাই। কোনো Technology যতই জনপ্রিয় হোক, সেটা ব্যবহার করার একটা কারণ থাকতে হবে। কারণ ছাড়া যোগ করা প্রতিটা Component ভবিষ্যতে আপনার জন্য বাড়তি Complexity তৈরি করবে।

শুরুতে হয়তো সবকিছুই ভালো চলছিল। কয়েক মাস পরে User বাড়তে শুরু করল। দেখা গেল Database-কে একই Query হাজার হাজার বার Execute করতে হচ্ছে। তখন কেউ প্রস্তাব দিল, "এই Data-গুলো কিছু সময়ের জন্য Memory-তে রাখলে কেমন হয়?"

সেখান থেকেই Cache-এর প্রয়োজন তৈরি হলো।

আরও কিছুদিন পরে দেখা গেল Order করার সময় Invoice তৈরি, Email পাঠানো, Notification পাঠানো, সব কাজ একসাথেই হচ্ছে। User-কে কয়েক সেকেন্ড অপেক্ষা করতে হচ্ছে। এবার প্রশ্ন হলো, এই সব কাজ কি Response দেওয়ার আগেই শেষ করতে হবে?

সেখান থেকে Background Worker বা Queue-এর প্রয়োজন তৈরি হলো।

আবার কোনো সময় হয়তো Search Feature এড করতে গিয়ে দেখলেন, শুরুতে LIKE দিয়েই কাজ চলে যাচ্ছিল। এমনকি Database-এর নিজের Full Text Search দিয়েও অনেক দূর যাওয়া যায়। PostgreSQL-এর tsvector কিংবা pg_trgm দিয়ে বানান ভুল আর আংশিক শব্দও অনেকটাই সামলানো যায়।

আসল চাপটা আসে অন্য দিক থেকে। কেউ "মোবাইল" লিখলে আগে ফোন দেখাবে নাকি মোবাইল কভার, সেটা কে ঠিক করবে? নামের সাথে মিললে বেশি গুরুত্ব, নাকি Description-এ মিললে? এর সাথে যোগ হয় Synonym, Category অনুযায়ী কোন Filter-এ কয়টা Product আছে সেই গোনা, আর প্রতিটা অক্ষরে Suggestion দেখানোর চাহিদা।

এগুলো Database দিয়ে করা অসম্ভব না। কিন্তু Query জটিল হতে থাকে, আর Search-এর পুরো ভারটা গিয়ে পড়ে সেই একই Database-এর উপর, যেটা ঠিক সেই সময়ে Order-ও নিচ্ছে। তখন Search-এর জন্য আলাদা একটা System ব্যবহার করার কথা ভাবা হলো।

খেয়াল করলে একটা বিষয় বুঝতে পারবেন। প্রতিবারই একটা Pattern অনুসরণ করা হয়েছে।

• প্রথমে একটা সমস্যা এসেছে।

• তারপর সেই সমস্যার সমাধান নিয়ে চিন্তা করা হয়েছে।

• সবশেষে প্রয়োজন হলে নতুন একটা Component এড করা হয়েছে।

অর্থাৎ বড় System-এর Architecture সব সময় শুরু থেকেই জটিল হয় না। বরং System বড় হওয়ার সাথে সাথে সেটা ধীরে ধীরে পরিবর্তিত হয়।

একটা Food delivery startup-এর সমস্যার সাথে একটা Ride Sharing Platform-এর সমস্যা এক হবে না। আবার একটা E-commerce Website-এর চাহিদাও Social Media Platform-এর মতো না। সবার সমস্যা আলাদা, তাই সমাধানও আলাদা। আবার একেকজনের ইউজারবেইজ, স্পেসিফিক বিজনেস নীড আলাদা, এ কারণেও অনেক ক্ষেত্রে তাদের আর্কিটেকচার ভিন্ন।

এমনকি সফটওয়্যার ইঞ্জিনিয়ারিং এর একটা অন্যতম বেস্ট প্র্যাকটিস হলো "Premature optimization" এভয়েড করা এবং অপ্রয়োজনে সিস্টেমকে জটিল না করা।

আমরা অনেক সময় বর্তমান কমপ্লেক্স Architecture Diagram-টা দেখি, কিন্তু সময়ের সাথে পরিবর্তিত হয়ে সেখানে পৌঁছানোর গল্পটা জানি না। অথচ Backend বোঝার জন্য Diagram-এর চেয়ে সেই যাত্রাটা অনেক বেশি গুরুত্বপূর্ণ।

কারণ Redis, Queue কিংবা CDN, এগুলোর কোনোটাই গল্পের শুরু না।

গল্পের শুরু সবসময় একটা সমস্যা দিয়ে।

আর Backend-এর বাকি গল্পটা সেই সমস্যার সমাধান খুঁজে বের করার দুঃসাহসিক যাত্রা!

Backend-এর Component-গুলো আসলে কেন আছে?

Backend শেখার সময় একটা জিনিস আমার কাছে সবসময়ই একটু অদ্ভুত লাগে।

আমরা সাধারণত Component দিয়েই শুরু করি।

Database, Redis, Queue, Load Balancer, Search Engine, এগুলোর একটা তালিকা বানাই। তারপর একটার পর একটা শেখার চেষ্টা করি। এতে অবশ্য সমস্যা নেই। কিন্তু কয়েক মাস পরে যখন কোনো বড় System-এর Architecture Diagram দেখি, তখন আবার সবকিছু নতুন মনে হয়।

কারণ আমরা Component চিনেছি, কিন্তু সেগুলোর প্রয়োজনটা বুঝিনি।

ধরুন, একটা Project-এ Redis ব্যবহার করা হয়েছে।

এই জায়গায় অনেকের প্রথম প্রশ্ন হয়, "Redis কী?"

আমার মনে হয়, আরও দরকারি প্রশ্ন হলো, "Redis কেন?"

এই দুই প্রশ্নের মধ্যে পার্থক্য আছে।

প্রথম প্রশ্নের উত্তর Documentation-এ পাওয়া যাবে। Redis কীভাবে Data Store করে, কী ধরনের Data Structure Support করে, Persistence কীভাবে কাজ করে, এসব খুব সহজেই জানা যায়।

কিন্তু দ্বিতীয় প্রশ্নের উত্তর Documentation-এ লেখা থাকে না।

সেটা লুকিয়ে থাকে Project-এর সমস্যার মধ্যে।

একটা ছোট উদাহরণ দিই।

ধরুন, আপনার একটা API আছে, যেটা Product List দেখায়। শুরুতে খুব বেশি User নেই। Database থেকে Data আনতে ২০–৩০ মিলিসেকেন্ড লাগছে। সবকিছু ঠিকঠাকই চলছে।

কিছুদিন পরে User অনেক বেড়ে গেল। একই API দিনে কয়েক লাখ বার Call হচ্ছে। লক্ষ্য করলেন, Database-এর বেশিরভাগ সময় একই Query বারবার Execute করতেই চলে যাচ্ছে।

এই জায়গায় এসে প্রশ্নটা আর Redis-এর না।

প্রশ্নটা হলো, একই কাজ কি প্রতিবারই Database-কে করতে হবে?

যদি উত্তর "না" হয়, তাহলে Cache নিয়ে ভাবা শুরু করা যায়। Redis তার একটা জনপ্রিয় Implementation। কিন্তু একমাত্র সমাধান না। কারণ আপনি চাইলে Memcached বা অন্য কোনো in-memory সলিউশন ব্যবহার করতে পারেন।

অর্থাৎ 'Redis কোথায় ব্যবহার করা যায়' এটা দিয়ে চিন্তা শুরু করা যাবে না। চিন্তা করতে হবে আমাদের কি আসলে ডাটা Cache করলে প্রব্লেমটা সল্ভ হবে?

Queue-এর ক্ষেত্রেও বিষয়টা আলাদা না।

একজন User Order করার পর Invoice তৈরি হচ্ছে, Email যাচ্ছে, Notification পাঠানো হচ্ছে। সবকিছু শেষ হতে কয়েক সেকেন্ড লেগে যাচ্ছে। এখন চাইলে আরও শক্তিশালী Server ব্যবহার করতে পারেন। আবার এটাও ভাবতে পারেন, এই সব কাজ User-এর Response পাওয়ার আগে শেষ হওয়া কি সত্যিই জরুরি?

প্রশ্নটা একটু বদলাতেই সমাধানও বদলে গেল।

Background-এ কাজ করার দরকার তৈরি হলো।

তারপর Queue এলো।

আমি ইচ্ছা করেই Redis, Queue কিংবা Search Engine-এর ভেতরের কাজ নিয়ে আলোচনা করছি না।

কারণ এই বইয়ের উদ্দেশ্য সেগুলো শেখানো না।

আমি বরং একটা অভ্যাস তৈরি করতে চাই।

পরেরবার যখন নতুন কোনো Technology দেখবেন, নিজেকে একটা প্রশ্ন করবেন:

শুরুতে হয়তো উত্তরটা জানা থাকবে না।

সেটা স্বাভাবিক। উত্তরটা জানার জন্য 'খোঁজ দ্য সার্চ' শুরু করবেন।

ধীরে ধীরে দেখবেন, Backend শেখাটা অনেক সহজ হয়ে গেছে। কারণ তখন আর Technology-গুলোকে আলাদা আলাদা বিষয় মনে হবে না। বরং একটা বড় ছবির ছোট ছোট অংশ মনে হবে।

আমার কাছে Backend শেখার সবচেয়ে মজার দিক এটাই।

নতুন কোনো Tool দেখলে এখন আর প্রথমে তার Feature List পড়তে ইচ্ছা করে না।

বরং জানতে ইচ্ছা করে, কোন Engineer কোন সমস্যায় পড়ে এটা বানানোর প্রয়োজন অনুভব করেছিলেন।

অনেক সময় সেই গল্পটা Technology-টার চেয়েও বেশি interesting হয়।

সব সমস্যার সমাধান নতুন Technology না

Backend নিয়ে কাজ করতে করতে একটা বিষয় ধীরে ধীরে বুঝতে শুরু করবেন।

কোনো System-এর সমস্যা দেখলেই নতুন Technology এড করতে হবে, এমন কোনো নিয়ম নেই।

শুনতে বিষয়টা খুব সাধারণ মনে হতে পারে। কিন্তু বাস্তবে আমরা অনেক সময় উল্টোটা করি।

ধরুন, একটা API আগের চেয়ে একটু স্লো Response দিচ্ছে। সঙ্গে সঙ্গে মনে হতে পারে, Cache এড করা দরকার। আবার কেউ হয়তো বলবে Database বদলাতে হবে। আরেকজন বলবে Microservices-এ চলে যাওয়ার সময় হয়ে গেছে।

সেটা তো করাই যায়!

কিন্তু তার আগে একটা বিষয় বোঝা দরকার।

সমস্যাটা আসলে কোথায়?

আমরা অনেক সময় Solution নিয়ে এত ব্যস্ত হয়ে যাই যে Problem-টাই ঠিকমতো বুঝে উঠি না।

একটা উদাহরণ দেখি।

ধরুন, Product List দেখানোর একটা API হঠাৎ স্লো হয়ে গেছে। প্রথমে মনে হলো Database-এর সমস্যা। পরে দেখা গেল Database না, Application-ই একই Query তিনবার করছে। Query একবারে নামিয়ে আনতেই Response Time অর্ধেক হয়ে গেল।

এখানে Redis এড করলে কী হতো?

হয়তো সমস্যাটা কিছুটা কমে যেত।

কিন্তু আসল সমস্যাটা থেকেই যেত।

আবার এমনও হতে পারে, Database Query-টাই ঠিকমতো লেখা হয়নি। একটা Index এড করলেই পুরো সমস্যার সমাধান হয়ে যায়।

অর্থাৎ একই লক্ষণ দেখে ভিন্ন ভিন্ন সিদ্ধান্তে পৌঁছানো যায়।

তাই একজন ভালো Backend Engineer-এর প্রথম কাজ Solution বেছে নেওয়া না।

প্রথম কাজ হলো সমস্যাটা বোঝা।

আরেকটা বিষয়ও খেয়াল করার মতো।

আমরা সাধারণত বড় কোম্পানির Engineering Blog পড়তে ভালোবাসি। Netflix কীভাবে Streaming করে, Uber কীভাবে Scale করেছে, Discord কীভাবে লক্ষ লক্ষ Connection Handle করে, এসব পড়তে সত্যিই ভালো লাগে।

কিন্তু একটা ছোট সমস্যা আছে।

আমরা অনেক সময় তাদের Solution দেখি, কিন্তু তাদের Problem দেখি না।

Netflix যে সমস্যার সমাধান করছে, সেটা হয়তো আপনার Project-এ কোনো দিনই আসবে না। একইভাবে, একটা Startup-এর Architecture দেখে Facebook বানানোর চেষ্টা করাও খুব একটা অর্থপূর্ণ না।

কারণ Engineering Decision সবসময় Context-এর উপর নির্ভর করে।

একই Solution এক Project-এ অসাধারণ কাজ করতে পারে, আবার অন্য Project-এ সেটাই অপ্রয়োজনীয় Complexity তৈরি করতে পারে।

Software Engineering-এ একটা কথার প্রচলন আছে।

এই কথাটার গভীরতা আমি অনেক পরে বুঝেছি।

আমরা অনেক সময় শুরুতেই System-কে ভবিষ্যতের জন্য Optimize করতে চাই। অথচ ভবিষ্যতে যে সমস্যা আসবে বলে ধরে নিচ্ছি, সেটা হয়তো কোনো দিনই আসবে না।

তার চেয়ে সহজ একটা System দিয়ে শুরু করা অনেক সময় ভালো সিদ্ধান্ত।

যখন সত্যিই নতুন সমস্যা আসবে, তখন সেই সমস্যার জন্য উপযুক্ত সমাধান যোগ করা যাবে।

এভাবে এগোলে System-ও সহজ থাকে, আর প্রতিটা সিদ্ধান্তের পেছনেও একটা পরিষ্কার কারণ থাকে।

আমার কাছে Backend Engineering-এর সবচেয়ে সুন্দর দিক সম্ভবত এটাই।

এখানে "সবচেয়ে আধুনিক Technology" ব্যবহার করাটাই লক্ষ্য না।

লক্ষ্য হলো, যে সমস্যাটা সামনে আছে, সেটার জন্য সবচেয়ে যুক্তিসঙ্গত সমাধান খুঁজে বের করা।

Architecture আসলে সিদ্ধান্তের গল্প

কয়েক বছর আগে আমি Backend শেখার সময় একটা ভুল ধারণা নিয়ে এগোতাম।

মনে হতো, ভালো Architecture মানে অনেকগুলো Technology একসাথে ব্যবহার করা। Redis আছে, Queue আছে, CDN আছে, Search Engine আছে, মানে System-টা নিশ্চয়ই অনেক ভালোভাবে Design করা হয়েছে।

পরে বুঝেছি, Architecture-কে এভাবে দেখাটা ঠিক না।

একটা Architecture Diagram আসলে আমাদের শেষ অবস্থাটা দেখায়। কিন্তু সেখানে পৌঁছানোর গল্পটা দেখায় না।

ধরুন, আপনি একটা Project-এ যোগ দিলেন। Diagram খুলে দেখলেন Redis আছে। আপনার কাছে তখন দুটো পথ খোলা।

প্রথম পথ হলো Redis কীভাবে কাজ করে, সেটা বোঝা।

দ্বিতীয় পথ হলো, Project-এর অন্য Developers-দের জিজ্ঞেস করা, "Redis এড করার প্রয়োজনটা কেন হলো?"

আমার অভিজ্ঞতায়, দ্বিতীয় প্রশ্নটা অনেক বেশি গুরুত্বপূর্ণ।

কারণ উত্তরটা হয়তো এমন হতে পারে:

অথবা,

হয়তো এমনও হতে পারে, "আসলে এখন আর Redis-এর দরকার নেই। অনেক বছর আগে একটা সমস্যার জন্য এড করা হয়েছিল, কিন্তু পরে System বদলে গেছে।"

এই উত্তরগুলো শুধু Redis সম্পর্কে কিছু বলে না।

এগুলো পুরো System-এর ইতিহাস সম্পর্কে ধারণা দেয়।

আমি অনেক সময় নতুন Project-এ গিয়ে Code-এর আগে Git History দেখি।

কে কী পরিবর্তন করেছে, কেন করেছে, কোন Feature-এর পরে কোন Refactoring হয়েছে, এসব দেখলে Project-টাকে বোঝা অনেক সহজ হয়।

আমার কাছে Architecture-ও অনেকটা সেরকম।

এটা শুধু Component-এর তালিকা না।

এটা একটা Project-এর Decision History।

কোন সময়ে কোন সমস্যাটা গুরুত্বপূর্ণ হয়ে উঠেছিল, আর সেই সময়ে Team কী সিদ্ধান্ত নিয়েছিল, Architecture তারই একটা ছবি।

এই দৃষ্টিভঙ্গিটা Backend শেখার ক্ষেত্রেও কাজে লাগে।

ধরুন, আজ একটা নতুন Technology জনপ্রিয় হলো।

আপনি চাইলে সেটা ব্যবহার করা শিখতে পারেন।

কিন্তু যদি না জানেন কোন সমস্যার সমাধান করার জন্য এটা তৈরি হয়েছে, তাহলে খুব দ্রুতই আরেকটা নতুন Technology এসে সেই জায়গা নিয়ে নেবে।

তখন আবার শুরু থেকে শেখা লাগবে।

অন্যদিকে, যদি সমস্যাটা বুঝে ফেলেন, তাহলে Technology বদলালেও খুব একটা সমস্যা হবে না।

নতুন Tool শিখতে সময় লাগবে, কিন্তু কেন শিখছেন, সেটা পরিষ্কার থাকবে।

এই লেখায় আমি ইচ্ছা করেই অনেক বিষয় এড়িয়ে গেছি।

• Redis-এর Command নিয়ে কথা বলিনি।
• Queue-এর Implementation নিয়েও না।
• Load Balancer কীভাবে Request ভাগ করে, সেটাও আলোচনা করিনি।

এর কারণ এগুলো গুরুত্বপূর্ণ না, তা না।

বরং এগুলো শেখার আগে একটা ভিত্তি তৈরি করা বেশি গুরুত্বপূর্ণ বলে আমার মনে হয়েছে।

কারণ Backend-এর Tool বদলাবে।

Framework বদলাবে।

Cloud Provider বদলাবে।

কিন্তু একটা বিষয় খুব একটা বদলাবে না।

একজন Engineer-এর কাজ সবসময়ই একটা সমস্যা বোঝা, সম্ভাব্য সমাধানগুলো নিয়ে চিন্তা করা, তারপর Context অনুযায়ী সবচেয়ে যুক্তিসঙ্গত সিদ্ধান্ত নেওয়া।

হয়তো এই কারণেই একই Technology ব্যবহার করেও দুইজন Developer একরকম System Design করতে পারেন না।

AI যুগে Backend Engineer-এর কাজ কী?

গত কয়েক বছরে Software Development অনেক বদলে গেছে।

আগে Documentation পড়ে যেটা বের করতে কয়েক ঘণ্টা লাগত, এখন AI-কে একটা Prompt লিখলেই অনেক সময় তার একটা কাজ চালানোর মতো উত্তর পাওয়া যায়। Boilerplate Code লেখা, সাধারণ API তৈরি করা, এমনকি Unit Test লেখার মতো কাজেও AI বেশ ভালো সাহায্য করতে পারে।

এ কারণে অনেকের মনেই একটা প্রশ্ন আসে।

তাহলে Backend শেখার দরকার কী?

আমার মনে হয়, এই প্রশ্নটার উত্তর খুঁজতে হলে আমাদের আবার বইয়ের শুরুতে ফিরে যেতে হবে।

এতক্ষণ আমরা Redis, Queue কিংবা Architecture নিয়ে যত কথা বলেছি, তার কোনোটার মূল বিষয়ই Technology ছিল না।

মূল বিষয় ছিল সিদ্ধান্ত।

• কখন Cache ব্যবহার করা উচিত?
• কখন একটা সাধারণ Database-ই যথেষ্ট?
• কখন নতুন Component এড করলে লাভের চেয়ে Complexity বেশি বাড়বে?

এই প্রশ্নগুলোর উত্তর AI Documentation থেকে পড়ে বলতে পারবে না। কারণ এর উত্তর এক Project থেকে আরেক Project-এ বদলে যায়।

ধরুন, আপনি AI-কে বললেন:

AI হয়তো কয়েকটা সম্ভাব্য সমাধান বলবে।

Cache ব্যবহার করতে পারে।

Database Optimize করতে বলতে পারে।

Background Worker-এর কথা বলতে পারে।

কিন্তু AI একটা জিনিস জানে না।

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

• Database-ই কি স্লো?
• নাকি Application অপ্রয়োজনীয় কাজ করছে?
• নাকি সমস্যাটা Network-এ?
• সিস্টেমে নতুন কম্পোনেন্ট যুক্ত করতে বা সিস্টেম স্কেল করতে যেই খরচ হবে সেটা কি আমি এখন করতে পারবো নাকি আমাকে 'আউট অফ দ্য বক্স' কোনো সলিউশনে যেতে হবে?

এই Context-টা এখনো আপনাকেই বুঝতে হবে।

আমার মনে হয়, AI একটা নতুন Skill-এর গুরুত্ব আরও বাড়িয়ে দিয়েছে।

সেটা হলো সঠিক প্রশ্ন করার ক্ষমতা।

কারণ প্রশ্নটা যদি ঠিক না হয়, উত্তর যত ভালোই হোক, খুব একটা কাজে আসবে না।

এখন পর্যন্ত এই বইয়ে আমরা বারবার চেষ্টা করেছি Technology-এর আগে প্রশ্নগুলো নিয়ে ভাবতে।

• Redis-এর আগে:কেন Cache দরকার?
• Queue-এর আগে:কেন কিছু কাজ পরে করা ভালো?
• Architecture-এর আগে:কোন সিদ্ধান্তগুলো ধীরে ধীরে একটা System-কে বদলে দিল?

এই প্রশ্নগুলোই একজন Engineer-কে আলাদা করে।

আমি বরং AI-কে আরেকভাবে দেখি।

আগে একজন Engineer-এর অনেক সময় যেত Syntax মনে রাখতে, Documentation পড়তে বা Boilerplate Code লিখতে।

এখন সেই সময়ের একটা বড় অংশ AI কমিয়ে দিতে পারে।

ফলে আমাদের আরও বেশি সময় দেওয়ার সুযোগ তৈরি হয়েছে এমন বিষয়গুলোতে, যেগুলো এখনো মানুষের Judgement এর উপর নির্ভর করে।

• সমস্যাটা আসলে কোথায়?
• কোন সমাধানটা সবচেয়ে সহজ?
• আজ একটা সিদ্ধান্ত নিলে ছয় মাস পরে তার প্রভাব কী হবে?

এই প্রশ্নগুলোর উত্তর এখনো Prompt দিয়ে বের করা যায় না।

তাই AI-এর কারণে Backend শেখার গুরুত্ব কমে গেছে, আমি অন্তত তা মনে করি না।

বরং উল্টোটা।

শুধু Code লিখতে জানলেই যেখানে আগে অনেক কাজ করা যেত, এখন সেখানে System বুঝতে পারা, ভালো প্রশ্ন করতে পারা আর সঠিক সিদ্ধান্ত নিতে পারার গুরুত্ব আরও বেড়েছে।

হয়তো ভবিষ্যতে Technology বদলাবে।

Framework বদলাবে।

AI আরও দক্ষ হবে।

কিন্তু একটা বিষয় খুব সহজে বদলাবে না।

কোনো System-এর প্রয়োজন বুঝে, তার জন্য যুক্তিসঙ্গত একটা সমাধান খুঁজে বের করার কাজটা এখনো একজন Engineer-কেই করতে হবে।

আর আমার কাছে Backend শেখার আসল উদ্দেশ্যও সেটাই।

এরপর কী?

আপনি যদি এই পর্যন্ত পড়ে থাকেন, তাহলে একটা বিষয় হয়তো খেয়াল করেছেন।

এই বইয়ে আমি খুব বেশি Technology নিয়ে কথা বলিনি।

• Redis-এর Command নিয়ে আলোচনা করিনি।
• Kafka কীভাবে কাজ করে, সেটাও না।
• Docker দিয়ে Application Deploy করার ধাপও দেখাইনি।

ইচ্ছা করেই করিনি।

কারণ আমার বিশ্বাস, Backend শেখার শুরুটা হওয়া উচিত অন্যভাবে।

কোনো Technology শেখার আগে বোঝা দরকার, সেটার প্রয়োজন কেন হলো। আর সেই প্রশ্নের উত্তর খুঁজতে গিয়েই ধীরে ধীরে Architecture, System Design কিংবা Scalability-এর মতো বিষয়গুলো অনেক সহজ হয়ে যায়।

এই ছোট্ট বইটার উদ্দেশ্য ছিল সেই শুরুটা করে দেওয়া।

তবে এটাও সত্যি, শুধু Mental Model দিয়ে Backend শেখা শেষ হয় না।

• একটা সময় আপনাকে API লিখতে হবে।
• Database Design করতে হবে।
• Authentication নিয়ে কাজ করতে হবে।
• Background Job লিখতে হবে।
• Caching ব্যবহার করতে হবে।
• Production-এ Application Deploy করতে হবে।

আর তখনই Theory-এর সাথে Practice-এর পার্থক্যটা বোঝা শুরু হবে।

আমার Backend Cohort-এর মূল উদ্দেশ্যও এখানেই।

আমি সেখানে শুধু language বা Framework শেখানোর চেষ্টা করি না।

আমরা কনসেপ্টগুলো বোঝার চেষ্টা করি।

প্রব্লেম সিনারিও দেখি, সেই পরিস্থিতিতে কী কী সমাধান হতে পারে সেটা সামনে রাখি।

কোন সমাধানের সুবিধা কী, সীমাবদ্ধতা কোথায়, কখন একটা সিদ্ধান্ত ভালো, আর কখন একই সিদ্ধান্ত ভবিষ্যতে সমস্যা তৈরি করতে পারে সেগুলো আলোচনা করি।

অর্থাৎ, আমরা শুধু Code লিখি না। Code-এর পেছনের সিদ্ধান্তগুলো নিয়েও কথা বলি।

কারণ বাস্তব Project-এ বেশিরভাগ সময় চ্যালেঞ্জটা Code লেখা না। চ্যালেঞ্জটা হলো, কোন Code লেখা উচিত, সেই সিদ্ধান্ত নেওয়া।

যদি এই বইটা পড়ে আপনার মনে হয় Backend-কে আগে যেভাবে দেখতেন, এখন একটু অন্যভাবে দেখছেন, তাহলে আমার বিশ্বাস Cohort-টাও আপনার ভালো লাগবে ইনশা'আল্লাহ।

কারণ এই বইয়ে আমরা কেবল আলোচনার শুরুটা করেছি।

Cohort-এ আমরা সেই আলোচনাকে বাস্তব Project-এর মাধ্যমে আরও অনেক দূর নিয়ে যাব।

কোহোর্টে যা যা থাকছে

• ১০ সপ্তাহের Live Class: ৯টি টপিক, সাথে AI নিয়ে ২টি বোনাস ক্লাস
• প্রতিটি টপিকের জন্য একটি Q&A সেশন: প্রতিটা টপিক নিয়ে ডেডিকেটেডলি প্রশ্ন করার সুযোগ
• নিজের হাতে বানানো একটি সত্যিকারের Product: আমার গাইড আর রিভিউ সহ, খেলনা প্রজেক্ট না
• Private Discord Channel: ক্লাসের বাইরে প্রশ্ন করার জন্য, নিয়মিত বিভিন্ন রিসোর্স শেয়ার করা হবে
• আরও ৩টি Megaminds কোর্স: ৳৩,৫০০ টাকার, একদম ফ্রি

কোহোর্টের দাম

শেষ করার আগে একটা কথাই বলতে চাই।

Software Engineering-এ Technology সবসময় বদলাবে।

আজ যেটা জনপ্রিয়, কয়েক বছর পরে হয়তো সেটা আর থাকবে না।

নতুন Framework আসবে।

নতুন Database আসবে।

AI আরও অনেক কিছু বদলে দেবে।

কিন্তু একজন ভালো Engineer-এর কাজ খুব বেশি বদলাবে না।

তিনি সবসময় বোঝার চেষ্টা করবেন:

• কোন সমস্যাটা সমাধান করতে হবে।

• কী কী বিকল্প আছে।

• আর এই পরিস্থিতিতে সবচেয়ে যুক্তিসঙ্গত সিদ্ধান্ত কোনটা।

Backend শেখার যাত্রায় যদি এই ছোট্ট লেখাটা আপনাকে সেই দিকেই এক ধাপ এগিয়ে নিতে পারে, তাহলেই আমার উদ্দেশ্য সফল।