Stateful vs Stateless Design
- ●Stateful server প্রতিটি client-এর তথ্য (session/state) নিজের memory-তে রাখে; ওই client-কে বারবার একই server-এ ফিরতে হয়।
- ●Stateless server কোনো client-তথ্য নিজে ধরে রাখে না; প্রতিটি request নিজেই সম্পূর্ণ, যেকোনো server সামলাতে পারে।
- ●Stateless সহজে horizontal scale করে ও fault-tolerant; state-কে cache/DB-তে সরিয়ে নিলে এটা পাওয়া যায়।
সমস্যাটা কী?
তোমার website-এ user login করল। এখন server-কে মনে রাখতে হবে "এই user কে, সে login করা আছে, তার cart-এ ৩টা জিনিস।" এই মনে-রাখা তথ্যটাই হলো State — আর login-কেন্দ্রিক এই তথ্যের গুচ্ছকে বলে Session।
প্রশ্ন: এই state কোথায় রাখবে?
- Server-এর নিজের memory-তে — দ্রুত, সহজ। কিন্তু তাহলে সেই server-ই শুধু এই user-কে চেনে। একে বলে Stateful design।
- Server-এর বাইরে কোথাও (cache/DB), আর server নিজে কিছু মনে রাখবে না — একে বলে Stateless design।
এক server থাকলে কোনো পার্থক্য নেই। কিন্তু load balancer-এর পেছনে যখন ৫টা server, তখন এই সিদ্ধান্ত পুরো architecture বদলে দেয়।
প্রথমটা: Stateful Design
Stateful server প্রতিটি client-এর state নিজের memory-তে ধরে রাখে। User A login করল server-1-এ; তার session আছে server-1-এর memory-তে। এখন user A-র পরের প্রতিটি request-ও যদি server-1-এ না যায়, নতুন server তাকে চিনবে না — মনে হবে সে logged out।
এই কারণে stateful design-এ Sticky Session লাগে — load balancer-কে দিয়ে একজন user-কে বারবার একই server-এ পাঠানো হয়।
সুবিধা:
- দ্রুত। State হাতের কাছেই (local memory), বাইরের কোথাও যেতে হয় না।
- কিছু কাজ (যেমন real-time game-এর live state, WebSocket connection) স্বভাবতই stateful।
অসুবিধা:
- Scaling কঠিন। Load বুঝে স্বাধীনভাবে যেকোনো server-এ request পাঠানো যায় না; sticky session লাগে।
- Fault tolerance দুর্বল। Server-1 crash করলে ওই memory-তে থাকা সব session উবে যায় — সব user হঠাৎ logged out।
- অসম load। কিছু server-এ ভারী user আটকে গেলে সেগুলো ঘামে, বাকিরা খালি বসে থাকে।
দ্বিতীয়টা: Stateless Design
Stateless server request-এর মাঝে কোনো client-তথ্য নিজে মনে রাখে না। প্রতিটি request নিজেই সম্পূর্ণ — দরকারি প্রমাণ (যেমন একটা token) request-এর সাথেই আসে, আর বড় state (cart, session details) রাখা হয় server-এর বাইরে একটা shared জায়গায় — যেমন Redis cache বা database। একে বলে Externalized State (state বাইরে সরানো)।
ফলে user A-র request server-1, server-3 বা যেকোনো server-এ গেলেও সমস্যা নেই — প্রত্যেকে দরকার হলে cache/DB থেকে A-র state তুলে নিতে পারে।
সুবিধা:
- সহজ horizontal scaling। যেকোনো server যেকোনো request সামলায়; load balancer স্বাধীনভাবে বিলি করতে পারে।
- Fault tolerance ভালো। একটা server মরলে অন্য server একই কাজ করে, কেউ logged out হয় না — কারণ state তো বাইরে।
- নতুন server যোগ বা বাদ দেওয়া সহজ (auto-scaling-এর জন্য আদর্শ)।
অসুবিধা:
- প্রতি request-এ state বাইরের store থেকে আনতে সামান্য বাড়তি কাজ/latency।
- একটা দ্রুত, নির্ভরযোগ্য shared store (Redis ইত্যাদি) লাগে; সেটাকেও scale ও সুরক্ষিত রাখতে হয়।
Stateful হলো এমন এক ডাক্তার যিনি প্রতিটি রোগীর সব তথ্য নিজের মাথায় রাখেন। তুমি সবসময় তাঁর কাছেই যেতে বাধ্য (sticky session)। তিনি ছুটিতে গেলে বা ভুলে গেলে তোমার সব তথ্য হারিয়ে গেল।
Stateless হলো এমন চেম্বার যেখানে প্রত্যেকের একটা ফাইল কেন্দ্রীয় রেকর্ড রুমে (cache/DB) থাকে। যে ডাক্তারই ফাঁকা থাকেন তিনিই দেখতে পারেন — ফাইল টেনে এনে। একজন ছুটিতে গেলে অন্যজন ঠিক একইভাবে সামলান, কারণ তথ্য কারও মাথায় নয়, ফাইলে।
পাশাপাশি তুলনা
| বিষয় | Stateful | Stateless |
|---|---|---|
| State কোথায় | server-এর local memory | বাইরে (cache/DB) বা request-এ |
| Sticky session দরকার? | হ্যাঁ | না |
| Horizontal scaling | কঠিন | সহজ |
| Server crash হলে | session হারায় | কিছু হারায় না |
| Latency | কম (local) | সামান্য বেশি (বাইরে যেতে হয়) |
| Load balancing | সীমাবদ্ধ | পূর্ণ স্বাধীন |
কখন কোনটা বেছে নেবে
- বেশিরভাগ web/API server — stateless রাখো। এটাই আধুনিক scalable design-এর ভিত্তি। Session/state Redis বা DB-তে সরিয়ে রাখো, login প্রমাণে token (যেমন JWT) ব্যবহার করো।
- Stateful রাখো শুধু তখনই যখন স্বভাবগতভাবে দরকার — যেমন live multiplayer game, voice/video call, একটানা WebSocket connection — যেখানে নিরন্তর live state ধরে রাখাটাই কাজের অংশ।
সবচেয়ে সাধারণ ভুল: শুরুতে session server-এর memory-তে রেখে দেওয়া (একটাই server বলে সমস্যা টের পাওয়া যায় না), পরে আরও server যোগ করলে user random logout হতে থাকে। তখন তড়িঘড়ি sticky session লাগানো হয়, যা scaling ও fault tolerance দুটোই দুর্বল করে। শুরু থেকেই state externalize করো — পরে অনেক কষ্ট বাঁচবে।
বাস্তব উদাহরণ
- REST API-গুলো ডিজাইন-নীতিগতভাবেই stateless — প্রতিটি request-এ auth token থাকে, server আগের কিছু মনে রাখে না।
- Netflix, Amazon-এর application server stateless; session/cart-এর মতো state রাখা হয় Redis/DynamoDB-র মতো বাইরের store-এ। তাই তারা নির্ভয়ে server যোগ/বাদ করে।
- Online multiplayer game server স্বভাবতই stateful — খেলার live অবস্থা memory-তে ধরে রাখতেই হয়, তাই player-রা নির্দিষ্ট game server-এ যুক্ত থাকে।
Interview-তে scaling প্রসঙ্গে নিজে থেকে বলো: "আমি application server-গুলো stateless রাখব এবং session/state Redis-এ externalize করব। এতে load balancer যেকোনো request যেকোনো server-এ পাঠাতে পারবে, আর কোনো server crash করলেও কেউ logged out হবে না।" — এই এক কথায় তুমি scaling, fault tolerance ও load balancing তিনটাই সংযুক্ত করে দেখালে।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Stateless server-এর মূল বৈশিষ্ট্য কোনটি?
2. Sticky session কী করে?
3. Stateless design horizontal scaling-এ সুবিধা দেয় কেন?