API Gateway
- ●API Gateway হলো সব client request-এর একটিমাত্র প্রবেশদ্বার, যা পেছনের অনেক microservice লুকিয়ে রাখে।
- ●এটি routing, authentication, rate limiting, request aggregation, SSL termination ও logging একসাথে সামলায়।
- ●BFF pattern-এ আলাদা client (mobile/web)-এর জন্য আলাদা gateway রাখা হয়; Kong, AWS API Gateway বাস্তব উদাহরণ।
সমস্যাটা কী?
ধরো তোমার একটা food delivery app আছে, আর পেছনে অনেকগুলো আলাদা microservice—user service, restaurant service, order service, payment service, notification service। এখন mobile app-কে কি এই ৫টা service-এর ঠিকানা আলাদা আলাদা জানতে হবে? প্রতিটার সাথে আলাদা করে login, SSL, rate limit সামলাতে হবে? একটা service-এর address বদলালে কি সব client app আপডেট করতে হবে?
এভাবে চললে client-এর কোড জটিল, নিরাপত্তা দুর্বল আর রক্ষণাবেক্ষণ দুঃস্বপ্ন হয়ে যায়। দরকার একটা একক দরজা—যার সাথে client কথা বলবে, আর সে ভেতরে ঠিক service-এ কাজ পাঠিয়ে দেবে। এটাই API Gateway।
মূল ধারণা
API Gateway হলো একটি single entry point যা সব client request গ্রহণ করে, প্রয়োজনীয় common কাজ (authentication, routing, rate limiting ইত্যাদি) সেরে সেগুলোকে সঠিক backend service-এ পাঠায় এবং response ফেরত দেয়।
মূল সুবিধা—যেসব কাজ প্রতিটি service-কে আলাদা করে করতে হতো (auth, logging, SSL, rate limit), সেগুলো একটা জায়গায় কেন্দ্রীভূত হয়। ফলে backend service-গুলো শুধু নিজের business logic নিয়ে থাকতে পারে, আর client পেছনের জটিলতা থেকে সুরক্ষিত থাকে।
কীভাবে কাজ করে
একটা request-এর যাত্রা এমন:
[Mobile/Web Client]
│
▼
[API Gateway] ── auth ✔ ── rate limit ✔ ── routing
│
┌───┼───────────┬───────────┐
▼ ▼ ▼ ▼
[User] [Order] [Payment] [Restaurant] services
API Gateway-র প্রধান দায়িত্ব
| দায়িত্ব | কী করে |
|---|---|
| Routing | কোন request কোন backend service-এ যাবে তা ঠিক করে |
| Authentication / Authorization | Token যাচাই করে—user বৈধ কিনা, তার অনুমতি আছে কিনা |
| Rate Limiting | এক client নির্দিষ্ট সময়ে কতবার call করতে পারবে তা সীমিত করে (abuse/DDoS ঠেকায়) |
| Request Aggregation | একাধিক service থেকে data এনে একটি response-এ মিলিয়ে দেয় |
| SSL Termination | HTTPS এখানেই decrypt করে, ভেতরে সহজ communication |
| Logging / Monitoring | সব traffic-এর কেন্দ্রীয় log ও metrics রাখে |
Request Aggregation উদাহরণ
Mobile-এ একটা order details screen-এ দরকার: order info, restaurant info, delivery status। Client যদি ৩টা আলাদা call করে, তাহলে ৩ round-trip—মোবাইল নেটওয়ার্কে slow। Gateway নিজে ৩টা service-এ গিয়ে data এনে একটাই combined response দেয়—client-এর জন্য ১ call।
API Gateway হলো একটা বড় সরকারি অফিসের তথ্য ও সেবা ডেস্ক (one-stop service center)। তুমি জমির খারিজ, ট্যাক্স আর সার্টিফিকেট—তিনটা আলাদা বিভাগের কাজে এলে আগের মতো তিন তলায় তিন রুমে দৌড়াতে হয় না। ডেস্কেই তোমার পরিচয় যাচাই হয় (authentication), লাইন ম্যানেজ হয় (rate limiting), আর ডেস্ক নিজেই তিন বিভাগে তোমার কাগজ পাঠিয়ে এক সাথে ফলাফল এনে দেয় (request aggregation)। তোমাকে জানতেই হয় না ভেতরে কোন বিভাগ কোথায়।
API Gateway বনাম Load Balancer বনাম Reverse Proxy
এই তিনটা প্রায়ই গুলিয়ে যায়। মূল পার্থক্য—কাজের স্তর ও বুদ্ধিমত্তা।
| বৈশিষ্ট্য | Load Balancer | Reverse Proxy | API Gateway |
|---|---|---|---|
| মূল কাজ | একই সার্ভারগুলোর মধ্যে traffic ভাগ | Server-এর সামনে বসে SSL/cache/security | API-aware একক প্রবেশদ্বার |
| বুদ্ধিমত্তা | কম (শুধু distribute) | মাঝারি | বেশি (auth, rate limit, aggregation) |
| কী বোঝে | শুধু network/connection | HTTP request | কোন API/endpoint, কোন service |
| Microservice-এ ভূমিকা | service-এর ভেতরের scaling | edge security | client-facing সব logic |
সহজ কথায়: API Gateway একটি বিশেষায়িত reverse proxy—যেটি reverse proxy-র সব কাজ তো করেই, উপরন্তু API-level বুদ্ধিমত্তা (routing by endpoint, auth, rate limit, aggregation) যোগ করে। আর load balancing প্রায়ই এর ভেতরেই একটা ফিচার হিসেবে থাকে।
কৌশল: BFF Pattern
একটাই gateway সব client-কে সেবা দিলে সমস্যা হয়—mobile-এর ছোট স্ক্রিনে কম data দরকার, web-এ বেশি, smart TV-তে আবার অন্যরকম। সবার জন্য এক response মানে কারও বেশি, কারও কম।
BFF (Backend For Frontend) pattern-এ প্রতিটি client type-এর জন্য আলাদা gateway রাখা হয়—Mobile BFF, Web BFF ইত্যাদি। প্রতিটি BFF তার নির্দিষ্ট client-এর চাহিদা অনুযায়ী response সাজায়, ঠিক যতটুকু দরকার ততটুকুই পাঠায়। ফলে প্রতিটি frontend team নিজের BFF নিজে নিয়ন্ত্রণ করতে পারে।
কখন ব্যবহার করবে / করবে না
Microservice architecture-এ API Gateway প্রায় অপরিহার্য—client-কে ডজনখানেক service-এর জটিলতা থেকে বাঁচায়। কিন্তু ছোট, একটা/দুটো service-এর simple app-এ gateway যোগ করা over-engineering—শুধু একটা reverse proxy-ই যথেষ্ট।
API Gateway সহজেই একটি single point of failure আর performance bottleneck হয়ে উঠতে পারে—সব traffic যেহেতু এর ভেতর দিয়ে যায়, এটা ডাউন হলে পুরো সিস্টেম ডাউন। তাই gateway নিজেই একাধিক instance-এ redundant করে চালাতে হবে, এবং এতে এত বেশি business logic ঢুকিও না যে এটা একটা "distributed monolith"-এ পরিণত হয়। Gateway-র কাজ cross-cutting concern সামলানো, business logic নয়।
বাস্তব উদাহরণ
- Netflix: microservice জগতে BFF pattern জনপ্রিয় করার অন্যতম পথিকৃৎ—বিভিন্ন device (TV, mobile, web)-এর জন্য আলাদাভাবে optimized gateway/edge layer ব্যবহার করে।
- AWS API Gateway: managed service—serverless backend (AWS Lambda)-এর সামনে বসে routing, auth (Cognito/IAM), throttling/rate limiting ও caching দেয়, নিজে server চালানো ছাড়াই।
- Kong ও Nginx: ওপেন-সোর্স/প্লাগইন-ভিত্তিক API Gateway, যেগুলো অনসংখ্য কোম্পানি নিজেদের on-premise বা cloud setup-এ ব্যবহার করে।
Interview-তে microservice design করতে গেলে শুরুতেই একটা API Gateway আঁকো এবং বলো এটা কোন cross-cutting কাজগুলো নেবে (auth, rate limit, routing)। এরপর interviewer যদি চাপ দেয়, "single point of failure" সমস্যাটা নিজেই তুলে ধরে বলো তুমি gateway-কে redundant ও horizontally scalable রাখবে—এতে বোঝা যাবে তুমি শুধু pattern চেনো না, এর ঝুঁকিও জানো।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. API Gateway-র মূল ভূমিকা কী?
2. Request aggregation বলতে কী বোঝায়?
3. BFF (Backend for Frontend) pattern-এর উদ্দেশ্য কী?