পাঠ্যক্রম খুলুন

প্রাথমিক পর্যায়

Stateful ও Stateless: session state কোথায় থাকবে

Stateful and Stateless Systems

এই পাঠের কুইজ ↓৫ মিনিট পড়াPHP 8.3+ · Laravel 12

আগে পড়ে নিনClient–Server: request ও response-এর সম্পর্ক ↗

এই পাঠের সূচিপত্র

এই পাঠে যা শিখবেন

Request-এর state কোথায় থাকে
Horizontal scaling-এ local state-এর সমস্যা
Stateless application-এর সীমা বোঝা

সমস্যা দিয়ে শুরু

একটি shop-এর দুটি Laravel server আছে। প্রথম request Server A-তে login করল। পরের request Server B-তে গেলে user আবার login screen দেখলেন। কারণ session file শুধু A-এর disk-এ ছিল। Load balancer যোগ হয়েছে, কিন্তু state কোথায় রাখা হবে সেই design বদলায়নি।

সহজ করে বুঝি

Stateful interaction-এ আগের request-এর remembered context পরের request প্রক্রিয়ায় লাগে। Stateless application tier বলতে সাধারণত বোঝায়, যে কোনো healthy instance প্রয়োজনীয় shared data বা request credential নিয়ে request সামলাতে পারে; শুধু একটি instance-এর memory-তে user-এর জরুরি state আটকে নেই।

Stateless মানে system-এ কোনো state নেই—এমন নয়। Orders database-এ থাকে, session Redis বা database-এ থাকতে পারে। গুরুত্বপূর্ণ পার্থক্য হলো state-এর ownership ও persistence app process থেকে আলাদা কি না।

পরিচিত একটি উপমা

একটি counter-এ দোকানি আপনার বাকি হিসাব নিজের মনে রাখেন। অন্য counter-এ গেলে তারা কিছু জানে না। Shared খাতায় হিসাব থাকলে যে counter-এই যান কাজ হয়। Redis session সেই shared খাতার মতো; তবে খাতা হারালে বা পড়া না গেলে কী হবে সেটিও ভাবতে হবে।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

Cookie session identifier বহন করে; app instance-গুলো একই session store ব্যবহার করে।

Diagram-এর text flow দেখুন

flowchart TD
 U[Browser with session cookie] --> L[Load Balancer]
 L --> A[Laravel A]
 L --> B[Laravel B]
 A --> S[(Shared Session Store)]
 B --> S
 A --> D[(Database)]
 B --> D

Browser cookie পাঠায়। Load balancer যেকোনো instance বেছে নেয়। সেই instance shared store থেকে session পড়ে user resolve করে। একই session encryption configuration ও application key সব instance-এ consistent থাকতে হবে। Shared store-এর reliability এখন application login reliability-র অংশ।

PHP ও Laravel-এ প্রয়োগ

Laravel-এর config/session.php-তে driver database বা redis করা যায়। নিচের array একটি সংক্ষিপ্ত configuration example; পুরো default config প্রতিস্থাপন করবেন না। Database driver হলে session table migration এবং Redis হলে PHP Redis client ও server configuration লাগবে।

// config/session.php — existing config-এর প্রাসঙ্গিক অংশ
return [
    'driver' => env('SESSION_DRIVER', 'database'),
    'connection' => env('SESSION_CONNECTION'),
    'lifetime' => 120,
    'encrypt' => true,
    'secure' => env('SESSION_SECURE_COOKIE', true),
    'http_only' => true,
    'same_site' => 'lax',
];

সুবিধা, সীমাবদ্ধতা ও trade-off

Shared session store instance replacement সহজ করে। কিন্তু store-এর network round trip ও availability dependency যোগ হয়। Sticky session সাময়িক workaround হতে পারে, তবে pinned server মারা গেলে local session হারাবে। JWT ব্যবহার করলেও revocation, expiry ও permissions update-এর trade-off দূর হয় না।

সাধারণ ভুল

Stateless মানে database দরকার নেই বলা।
Upload কেবল একটি app server-এর local disk-এ রাখা।
Worker restart করলে in-memory job state হারাবে কি না না ভাবা।
সব instance-এর application key ও cookie configuration ভিন্ন রাখা।

আরও একটু গভীরে

User session আর database connection এক ধরনের state নয়। Connection pooling process-level resource management; session হলো user interaction context। Autoscaling-এর আগে local file, memory cache, temporary export ও scheduled task ownership আলাদা করে audit করুন। সবকিছু shared storage-এ দিলেও coordinated writes-এর correctness নিজে তৈরি হয় না।

মনে রাখুন

State থাকে; প্রশ্ন হলো কোথায় এবং কার নিয়ন্ত্রণে।
Shared state app instance বদলানো সহজ করে।
একটি instance বন্ধ করে বাস্তবে session ও file access পরীক্ষা করুন।

নিজে চেষ্টা করুন

দুটি app instance দিয়ে পাঁচটি request চালানোর flow আঁকুন। Session local file-এ এবং shared database-এ থাকলে ফল কী হবে লিখুন।

নিজের বোঝা যাচাই করুন

1. Stateless app-এ order রাখা যায়?

হ্যাঁ। Order persistent database-এ থাকবে; app process-এর local memory-তে একমাত্র কপি থাকবে না।

2. Sticky session কি HA নিশ্চিত করে?

না। Pinned instance মারা গেলে তার local state হারাতে পারে।

3. Redis session মানেই স্থায়ী session?

না। Persistence, replication, eviction ও failure policy অনুযায়ী durability বদলায়।

4. Cookie-তে কী থাকে?

Driver অনুযায়ী বদলায়। Server-side session driver-এ সাধারণত session identifier থাকে; সব server-side data নয়।

5. Deploy-এর আগে কী পরীক্ষা করবেন?

Instance বদলালে login, upload access এবং চলমান কাজ সচল থাকে কি না পরীক্ষা করুন।

এই পাঠের কুইজ

এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।

এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।

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

সব বিষয় মিলিয়ে অনুশীলন করুন →

অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।