Client-Server Architecture
- ●Client-Server architecture-এ একপক্ষ (client) সেবা চায় আর আরেকপক্ষ (server) সেবা দেয়।
- ●যোগাযোগ হয় request/response মডেলে — client request পাঠায়, server response ফেরত দেয়।
- ●Thin vs thick client এবং multi-tier ভাগ বুঝলে প্রায় সব আধুনিক অ্যাপের ভিত্তি পরিষ্কার হয়।
সমস্যাটা কী?
ধরো তুমি একটা ছোট নোট রাখার অ্যাপ বানালে যেটা শুধু তোমার নিজের ল্যাপটপে চলে। সব data তোমার মেশিনেই থাকে। কিন্তু একদিন তুমি চাইলে — মোবাইল থেকেও একই নোট দেখতে, বন্ধুর সাথে শেয়ার করতে, আর অফিসের পিসি থেকেও খুলতে। এখন সমস্যা হলো: data যদি শুধু তোমার ল্যাপটপে থাকে, তাহলে অন্য ডিভাইস সেটা কোথায় পাবে?
এই সমস্যার সবচেয়ে পুরনো ও সফল সমাধান হলো Client-Server architecture। একটা কেন্দ্রীয় জায়গায় (server) data ও logic রাখো, আর যেকোনো ডিভাইস (client) সেখান থেকে চেয়ে নিক। Facebook, Gmail, bKash, Pathao — প্রায় সব অ্যাপই মূলত এই মডেলের উপর দাঁড়িয়ে আছে। তাই এটা না বুঝে System Design শুরু করা যায় না।
মূল ধারণা
Client-Server architecture হলো এমন একটা ডিজাইন যেখানে কাজ দুই ভূমিকায় ভাগ হয় — Client (যে সেবা চায়) এবং Server (যে সেবা দেয়)। তারা একটা নেটওয়ার্কের মাধ্যমে নির্দিষ্ট নিয়মে (protocol) কথা বলে।
এখানে মূল চিন্তাটা হলো দায়িত্ব ভাগ করা (separation of concerns)। Client-এর কাজ user-কে দেখানো আর input নেওয়া; server-এর কাজ data সংরক্ষণ, নিয়ম প্রয়োগ আর সঠিক উত্তর ফেরত দেওয়া।
Client হতে পারে তোমার মোবাইল অ্যাপ, ব্রাউজার, বা অন্য কোনো প্রোগ্রাম। Server হলো এমন একটা প্রোগ্রাম (এবং তার মেশিন) যেটা সবসময় চালু থাকে আর request-এর অপেক্ষায় বসে থাকে। একটা server একসাথে হাজার হাজার client-কে সেবা দিতে পারে, এটাই এর শক্তি।
কীভাবে কাজ করে
Request/Response চক্র
পুরো ব্যাপারটা ঘোরে একটা সাধারণ চক্রে, যাকে বলে Request/Response:
- Client request তৈরি করে — যেমন "আমার profile data দাও"।
- নেটওয়ার্কে পাঠানো হয় — সাধারণত HTTP protocol-এ, একটা URL ও method (GET/POST) সহ।
- Server request গ্রহণ করে — কে চাইছে, কী চাইছে যাচাই করে।
- Server প্রসেস করে — database থেকে data টানে, নিয়ম প্রয়োগ করে।
- Server response ফেরত দেয় — data + একটা status code (যেমন 200 = সফল, 404 = পাওয়া যায়নি)।
- Client response দেখায় — UI-তে রেন্ডার করে।
এই পুরো চক্র সাধারণত কয়েকশ মিলিসেকেন্ডে শেষ হয়।
Thin vs Thick Client
Client কতটা কাজ নিজে করে, তার উপর ভিত্তি করে দুই ধরনের:
| বৈশিষ্ট্য | Thin Client | Thick (Fat) Client |
|---|---|---|
| Logic কোথায় | বেশিরভাগ server-এ | বেশিরভাগ client-এ |
| উদাহরণ | সাধারণ ওয়েবপেজ, Gmail web | ভিডিও এডিটর, অনলাইন গেম |
| Offline কাজ | প্রায় অসম্ভব | অনেকটা সম্ভব |
| আপডেট | server-এ একবার | প্রতি ডিভাইসে আলাদা |
| নেটওয়ার্ক নির্ভরতা | অনেক বেশি | তুলনামূলক কম |
Thin Client হালকা — ভারী কাজ server করে। Thick Client ভারী — অনেক কাজ ডিভাইসেই হয়।
Tier বা স্তর
বড় সিস্টেমে কাজ আরও সাজানো হয় কয়েকটি tier-এ:
| Tier | নাম | দায়িত্ব |
|---|---|---|
| ১ | Presentation | UI, যা user দেখে |
| ২ | Application | business logic, নিয়ম |
| ৩ | Data | database, স্থায়ী data |
এই তিন স্তরের ভাগকে বলে Three-Tier architecture। প্রতিটি স্তর আলাদা থাকায় একটা পরিবর্তন করলে অন্যটায় কম প্রভাব পড়ে — যেমন UI বদলালে database ছুঁতে হয় না।
একটা রেস্টুরেন্ট ভাবো। তুমি (client) ওয়েটারকে অর্ডার দাও — এটা request। ওয়েটার রান্নাঘরে (server) সেটা পৌঁছায়, শেফ রান্না করে, তারপর ওয়েটার তোমার খাবার (response) এনে দেয়। তুমি জানো না রান্নাঘরে কী হচ্ছে — তোমার শুধু সঠিক খাবার দরকার। একই শেফ একসাথে অনেক টেবিলকে (অনেক client) সামলান। আর menu হলো protocol — কী চাওয়া যাবে আর কীভাবে চাইতে হবে তার নিয়ম।
সুবিধা ও অসুবিধা
সুবিধা:
- কেন্দ্রীয় নিয়ন্ত্রণ: data এক জায়গায়, তাই backup, security ও আপডেট সহজ। একবার server-এ ঠিক করলে সবাই পায়।
- যেকোনো ডিভাইস থেকে অ্যাক্সেস: মোবাইল, ল্যাপটপ, ট্যাব — সবাই একই data দেখে।
- স্কেল করা সহজ: চাপ বাড়লে আরও server যোগ করা যায়।
- নিরাপত্তা: গুরুত্বপূর্ণ logic ও data client-এর হাতে থাকে না, server-এ সুরক্ষিত থাকে।
অসুবিধা:
- Single point of failure: server বন্ধ হলে সব client আটকে যায়।
- নেটওয়ার্ক নির্ভরতা: ইন্টারনেট না থাকলে thin client প্রায় অকেজো।
- Server-এর খরচ: সবসময় চালু রাখা, scale করা — সবই খরচ ও রক্ষণাবেক্ষণ চায়।
- Latency: প্রতিটি কাজের জন্য নেটওয়ার্ক ঘুরে আসতে দেরি হতে পারে।
কখন ব্যবহার করবে / করবে না
ব্যবহার করবে যখন: একাধিক user বা ডিভাইসকে একই data শেয়ার করাতে হবে, data কেন্দ্রীয়ভাবে রাখতে হবে, কিংবা logic-কে user-এর নাগালের বাইরে নিরাপদে রাখতে হবে। প্রায় সব web ও mobile অ্যাপের জন্য এটাই ডিফল্ট।
এড়িয়ে যেতে পারো যখন: অ্যাপটা সম্পূর্ণ offline, একক-ব্যবহারকারী, আর কোনো শেয়ার করা data নেই — যেমন একটা সাধারণ ক্যালকুলেটর।
নতুনরা প্রায়ই গুরুত্বপূর্ণ যাচাই (যেমন দাম, ছাড়, বা permission) শুধু client-এ করে ফেলে। কখনোই client-কে বিশ্বাস করো না — user ব্রাউজার বা অ্যাপের কোড বদলে ফেলতে পারে। সব গুরুত্বপূর্ণ validation server-এ আবার করতে হবে। Client-এর validation শুধু ব্যবহারকারীর সুবিধার জন্য, নিরাপত্তার জন্য নয়।
বাস্তব উদাহরণ
bKash-এর কথা ধরো। তোমার মোবাইল অ্যাপ হলো client। তুমি যখন "Send Money" দাও, অ্যাপ একটা request পাঠায় bKash-এর server-এ। Server যাচাই করে তোমার balance আছে কিনা, PIN ঠিক কিনা, প্রাপক নম্বর বৈধ কিনা — এসব নিয়ম client-এ নয়, server-এ চলে। তারপর database-এ লেনদেন লিখে একটা response পাঠায়: "সফল" বা "ব্যর্থ"।
এখানে thin client পদ্ধতি — অ্যাপ শুধু সুন্দর করে দেখায়, আসল হিসাব আর নিরাপত্তা server-এর হাতে। কোটি কোটি ব্যবহারকারী একই server-গুলোর সাথে কথা বলে, আর bKash চাপ বাড়লে আরও server যোগ করে স্কেল করে। এটাই Three-Tier-এর জীবন্ত রূপ: অ্যাপ (presentation), লেনদেনের নিয়ম (application), আর account database (data)।
ইন্টারভিউতে যদি জিজ্ঞেস করে "client নাকি server-এ এই কাজটা করবে?", উত্তরের সোনালি নিয়ম মনে রাখো: trust ও correctness দরকার এমন সব কিছু server-এ, আর responsiveness দরকার এমন হালকা কাজ client-এ। এটা বললে তুমি নিরাপত্তা ও পারফরম্যান্স দুটোই বোঝো বলে স্পষ্ট হবে।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Client-Server মডেলে যোগাযোগ সাধারণত কোন ধরনের হয়?
2. Thin client বলতে কী বোঝায়?
3. Three-tier architecture-এ middle tier-এর প্রধান কাজ কী?