Reverse proxy, API gateway আর BFF — সার্ভারের সামনের দরজা

১ · Proxy মানে প্রতিনিধি — forward proxy বনাম reverse proxy

রাত ১০টায় একটি অনলাইন দোকানের অ্যাপে (কাল্পনিক) আপনি অর্ডার দিলেন। ফোন জানে শুধু একটি নাম — api.shop.example. DNS সেই নামের একটি ঠিকানা দিল, ফোন সেখানে TLS সংযোগ খুলে অনুরোধ পাঠাল (পর্ব ৭)। কিন্তু ওই ঠিকানার পেছনে আছে অর্ডার, পণ্য, পেমেন্ট আর নোটিফিকেশনের আলাদা সার্ভিস, প্রত্যেকটির কয়েকটি কপি। ফোন প্রথম যার সাথে কথা বলে, সে এদের কেউ নয়; সে একটি reverse proxy বা API gateway — সার্ভারগুলোর সামনের দরজা। পর্ব ৮-এ নকশা করা endpoint-গুলোর সামনে কে দাঁড়ায়, কী করে, আর কোথায় সে নিজেই বিপদ — এই পর্বের বিষয়।

Proxy শব্দের অর্থ প্রতিনিধি। প্রযুক্তির ভাষায়, proxy এমন একটি মধ্যস্থ প্রোগ্রাম, যে একদিকের অনুরোধ নিজে গ্রহণ করে, তারপর নিজের নামে আরেকটি অনুরোধ অন্যদিকে পাঠায়। তাই proxy থাকলে একটি নয়, দুটি আলাদা সংযোগ থাকে: client ↔ proxy আর proxy ↔ server. প্রশ্ন একটাই — প্রতিনিধিটি কার পক্ষে?

প্রযুক্তিগতভাবে দুটি প্রায় একই যন্ত্র — একই software (যেমন Squid) দুই ভূমিকাতেই চলতে পারে; পার্থক্য পক্ষ আর মালিকানায়। HTTP পড়ে ভার ভাগ করা load balancer (L7) আসলে একটি reverse proxy; আর L4 load balancer শুধু TCP সংযোগ এগিয়ে দেয়, HTTP খোলে না — বিস্তারিত পর্ব ১৪ (Load balancing)-এ। CDN হলো পৃথিবীজুড়ে ছড়ানো reverse proxy আর cache-এর জাল (পর্ব ১৭)। Proxy firewall আর WAF নিয়ে Computer Networks কোর্সের Firewall আর VPN পর্ব, আর proxy cache নিয়ে Web cache, proxy আর CDN পর্ব দেখুন।

২ · Reverse proxy কী কী করে — এক দরজায় নয়টি কাজ

অ্যাপ সার্ভার বানানো হয় ব্যবসার কাজের জন্য — অর্ডার নেওয়া, দাম হিসাব। কিন্তু ইন্টারনেটের মুখোমুখি দাঁড়ানোর আরও অনেক কাজ আছে, যা প্রতিটি অ্যাপে আলাদা করে লেখা অপচয় আর ঝুঁকি। Reverse proxy সেগুলো এক জায়গায় নেয়:

ধীর client-এর হিসাব — buffering কেন এত জরুরি

ধরা যাক একটি উত্তর ২ MB (যেমন একটি PDF রসিদ), অর্থাৎ ১৬ মেগাবিট। ব্যবহারকারীর mobile link ধরা যাক ১ Mbps — উত্তর পৌঁছাতে ১৬ সেকেন্ড। Proxy আর অ্যাপ সার্ভার একই ডেটা সেন্টারে, মাঝে ১ Gbps — একই উত্তর পার হতে ১৬ ms. Proxy না থাকলে অ্যাপের একটি worker (thread বা process) পুরো ১৬ সেকেন্ড শুধু byte ঠেলে; proxy থাকলে ১৬ ms পরেই সে মুক্ত। পর্ব ৪-এর Little-এর সূত্র দিয়ে হিসাব করুন — প্রতি সেকেন্ডে এমন ৫০টি অনুরোধ এলে একসাথে আটকে থাকা worker:

হাজার গুণ পার্থক্য। অ্যাপের thread pool-এ ২০০টি thread থাকলে proxy ছাড়া এই ধীর client-রাই সবগুলো দখল করবে, আর দ্রুত link-এর ব্যবহারকারীও সারিতে দাঁড়াবেন। ধীরে upload হওয়া body-ও proxy পুরোটা জমিয়ে এক টানে পাঠায়। তবে SSE, WebSocket বা চলমান stream-এ (পর্ব ১০) উত্তর জমালে real-time ভাবটাই নষ্ট — সেসব route-এ buffering বন্ধ, আর timeout দীর্ঘ সংযোগের উপযোগী।

TLS কোথায় শেষ হবে — তিনটি বিকল্প

• Termination: proxy-তে TLS খোলে, ভেতরে সাধারণ HTTP. সহজ, কিন্তু ধরে নেয় ভেতরের নেটওয়ার্ক বিশ্বস্ত।
• Re-encryption: proxy-তে খুলে কাজ সেরে নতুন TLS-এ backend-এ পাঠায়; ভেতরে প্রায়ই mTLS, যাতে দুই পক্ষই certificate দেখায়। CPU খরচ একটু বেশি, কিন্তু ভেতরের নেটওয়ার্ককে অন্ধ বিশ্বাস করতে হয় না।
• Passthrough: proxy TLS খোলেই না। Encryption শেষ পর্যন্ত অটুট, কিন্তু path দেখে routing, cache, header যোগ — কিছুই সম্ভব নয়; শুধু handshake-এ client-এর জানানো host নাম (SNI) দেখে ভাগ করা যায়।

Handshake আর certificate-এর বিস্তারিত Computer Networks কোর্সের TLS আর HTTPS পর্বে।

আসল client কে — X-Forwarded-For আর বিশ্বাসের নিয়ম

Proxy নিজের নামে নতুন সংযোগ খোলে, তাই backend দেখে proxy-র IP. আসল client-এর IP আর মূল protocol জানাতে proxy header যোগ করে — প্রচলিত X-Forwarded-For আর X-Forwarded-Proto; মানসম্মত রূপ Forwarded header (RFC 7239, ২০১৪)। কিন্তু client নিজেও এই header বানিয়ে পাঠাতে পারে। তাই backend মানটি বিশ্বাস করবে শুধু চেনা proxy থেকে এলে, আর একেবারে বাইরের proxy বাইরে থেকে আসা মান মুছে নিজের দেখা মান বসাবে। L4 load balancer HTTP পড়ে না, তাই সেখানে HAProxy-র PROXY protocol-এর মতো আলাদা ব্যবস্থা লাগে।

৩ · একটি Nginx-ধাঁচের config পড়া — উদাহরণ

নিচের config একটি সরল reverse proxy-র — HTTPS, দুটি path-এর routing, timeout আর একটি rate-limit-এর খসড়া। এটি পড়ে বোঝার জন্য; বাস্তবে নিজের Nginx-সংস্করণের অফিসিয়াল ডকুমেন্টেশনে প্রতিটি লাইন মিলিয়ে নিতে হবে।

# Illustrative only: a simplified reverse proxy for api.shop.example.
# Directive names and defaults differ between Nginx versions - check the docs.

limit_req_zone $binary_remote_addr zone=per_ip:10m rate=10r/s;   # rate-limit stub

upstream orders_v1 {
    server 10.0.1.11:8080 max_fails=3 fail_timeout=10s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=10s;
    keepalive 32;                         # idle connections kept open to backends
}
upstream catalog_v1 {
    server 10.0.2.21:8080;
    keepalive 16;
}

server {                                  # plain HTTP: only redirect to HTTPS
    listen 80;
    server_name api.shop.example;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    http2 on;                             # before 1.25.1: "listen 443 ssl http2;"
    server_name api.shop.example;
    ssl_certificate     /etc/nginx/tls/api.shop.example.crt;
    ssl_certificate_key /etc/nginx/tls/api.shop.example.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    client_max_body_size 1m;              # bigger request body -> 413
    proxy_http_version 1.1;               # needed for the keepalive pool
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Request-ID $request_id;
    proxy_connect_timeout 2s;
    proxy_read_timeout 5s;                # max gap between two reads -> else 504

    location /v1/orders/ {
        limit_req zone=per_ip burst=20 nodelay;
        limit_req_status 429;             # default would be 503
        proxy_pass http://orders_v1;
    }
    location /v1/ {
        proxy_pass http://catalog_v1;
    }
    location / {
        return 404;
    }
}

প্রতিটি অংশ কী বোঝায়, আর কোথায় মানুষ (এবং AI) প্রায়ই ভুল করে:

৪ · API gateway — API-র জন্য বিশেষ reverse proxy

সার্ভিস যখন অনেক (microservices, পর্ব ৪৭), প্রতিটিকে token যাচাই, quota গণনা আর log লেখা নিজে করতে হলে একই কোড বিশ জায়গায়, বিশ রকম বাগ নিয়ে। এমন সাধারণ চাহিদার নাম cross-cutting concern. API gateway এগুলো এক জায়গায় আনে। প্রযুক্তিগতভাবে এটি একটি L7 reverse proxy, কিন্তু ভাবে API, client-অ্যাপ, API key আর quota-র ভাষায়। Envoy-ভিত্তিক gateway, Kong-এর মতো open-source gateway বা cloud-এর managed gateway — সবাই এই কাজ করে।

পুরো ছবিটি একসাথে দেখুন — এই পর্বের বাকি সবকিছু এই নকশার কোনো না কোনো অংশ:

একটি অনুরোধ gateway-এর ভেতর দিয়ে

অ্যাপ পাঠাল GET /v1/orders/42. Gateway-এর ভেতরে অনুরোধটি ধাপে ধাপে এগোয়, আর প্রতিটি ধাপ সেখানেই থামিয়ে উত্তর দিতে পারে। “পরে” চাপুন; “ব্যর্থ হলে” সারিতে দেখুন কোন উত্তর ফেরত যেত:

Gateway নিজে যেসব status code দেয়

উত্তরটি সার্ভিসের, নাকি পথেই gateway দিয়েছে — status code দেখে আন্দাজ করা যায় (সাধারণ নিয়ম পর্ব ৮-এ):

নিজে চালিয়ে দেখুন — একটি ছোট gateway router

নিচের simulator-এ route table (host আর path-prefix → সার্ভিস, অনুমোদিত method, token লাগবে কি না) আর প্রতিটি client-এর জন্য একটি ছোট quota রাখা আছে। এগারোটি নমুনা অনুরোধে gateway কী সিদ্ধান্ত নেয়, দেখুন:

// A tiny API-gateway router: host + LONGEST path prefix -> service,
// method rules, a token check and a per-client quota for one time window.
const routes = [  // [host, path prefix, service, allowed methods, token needed?]
  ["api.shop.example", "/v1/", "catalog-v1", "GET", false],
  ["api.shop.example", "/v1/orders/", "orders-v1", "GET POST", true],
  ["api.shop.example", "/v2/orders/", "orders-v2", "GET POST", true],
  ["admin.shop.example", "/", "admin-ui", "GET", true],
];
const tokens = { "tok-rahim": "android-app", "tok-mitu": "web-app" };  // token -> client
const QUOTA = 3, used = {};  // tiny per-client quota per window; client -> count so far

function handle(method, host, path, token, ip) {
  const hits = routes.filter(([h, p]) => h === host && path.startsWith(p));
  if (!hits.length) return "404 no route";
  const [, prefix, svc, methods, auth] = hits.reduce((a, b) => (b[1].length > a[1].length ? b : a));
  if (!methods.split(" ").includes(method)) return "405 method not allowed on " + prefix;
  const client = auth ? tokens[token] : "ip:" + ip;   // anonymous callers counted by IP
  if (!client) return "401 missing or invalid token";
  if ((used[client] || 0) >= QUOTA) return "429 quota used up: " + client;
  used[client] = (used[client] || 0) + 1;
  return "200 " + svc + " [" + prefix + "] " + client + " " + used[client] + "/" + QUOTA;
}

const requests = [  // method host path token ip   ("-" = no token)
  "GET api /v1/products/42 - 10.0.0.5", "GET api /v1/orders/77 tok-rahim 10.0.0.6",
  "POST api /v1/orders/ - 10.0.0.6", "DELETE api /v1/products/42 - 10.0.0.5",
  "GET api /v1/orders tok-rahim 10.0.0.6", "GET api /v3/orders/1 tok-rahim 10.0.0.6",
  "GET pay /v1/orders/77 tok-rahim 10.0.0.6", "POST api /v2/orders/ tok-mitu 10.0.0.9",
  "GET api /v1/orders/78 tok-rahim 10.0.0.6", "GET api /v1/orders/79 tok-rahim 10.0.0.6",
  "GET api /v1/orders/80 tok-rahim 10.0.0.6",
];
for (const line of requests) {
  const [m, h, p, t, ip] = line.split(" ");
  console.log((m + " " + h + " " + p).padEnd(27) + handle(m, h + ".shop.example", p, t, ip));
}

GET api /v1/products/42    200 catalog-v1 [/v1/] ip:10.0.0.5 1/3
GET api /v1/orders/77      200 orders-v1 [/v1/orders/] android-app 1/3
POST api /v1/orders/       401 missing or invalid token
DELETE api /v1/products/42 405 method not allowed on /v1/
GET api /v1/orders         200 catalog-v1 [/v1/] ip:10.0.0.6 1/3
GET api /v3/orders/1       404 no route
GET pay /v1/orders/77      404 no route
POST api /v2/orders/       200 orders-v2 [/v2/orders/] web-app 1/3
GET api /v1/orders/78      200 orders-v1 [/v1/orders/] android-app 2/3
GET api /v1/orders/79      200 orders-v1 [/v1/orders/] android-app 3/3
GET api /v1/orders/80      429 quota used up: android-app

৫ · কোনটি gateway-তে, কোনটি সার্ভিসে — “smart gateway” ফাঁদ

সব অনুরোধ gateway দিয়ে যায় — তাই নতুন যেকোনো নিয়ম “gateway-তেই বসিয়ে দিই” বলা সবচেয়ে সহজ। নিয়মটি মনে রাখুন: gateway-তে যাবে অনুরোধ-স্তরের সাধারণ নীতি, যার উত্তর অনুরোধ দেখেই দেওয়া যায়; যে সিদ্ধান্তে ব্যবসার ডেটা বা নিয়ম লাগে, তা থাকবে সেই ডেটার মালিক সার্ভিসে।

৬ · BFF — প্রতিটি client-এর জন্য নিজের backend

একটি সাধারণ-উদ্দেশ্যের API সব client-কে একই উত্তর দেয়। কিন্তু client-রা আলাদা: মোবাইলের পর্দা ছোট, link ধীর, ব্যাটারি সীমিত; ওয়েবের পর্দা বড়; পার্টনার চায় স্থির চুক্তি। এক API সবার মন রাখতে গিয়ে কারও জন্যই ভালো হয় না — মোবাইল পায় অপ্রয়োজনীয় field আর অনেকগুলো call, ওয়েব দল নতুন field-এর জন্য API দলের সারিতে অপেক্ষা করে।

Backend for Frontend (BFF) pattern-এর উত্তর: প্রতিটি ব্যবহারকারী-অভিজ্ঞতার জন্য একটি পাতলা, আলাদা backend. নামটি জনপ্রিয় হয় Sam Newman-এর ২০১৫ সালের দিকের একটি লেখায়; প্রকাশিত লেখা অনুযায়ী তার আগেই কয়েকটি দল (যেমন SoundCloud-এর প্রকৌশলীরা) এভাবে কাজ করছিল। BFF-এর মূল কাজ aggregation: কয়েকটি সার্ভিস ডেকে একটি উত্তর বানানো, আর ছেঁটে client-এর মাপমতো করা।

একটি মোবাইল অ্যাপের হোম স্ক্রিনে লাগে তিনটি জিনিস: ব্যবহারকারীর profile, feed আর নোটিফিকেশনের সংখ্যা। ধরা যাক (শেখার জন্য গোল সংখ্যা): mobile link-এর RTT ১৫০ ms, CDN-এ ১ ms, CDN edge থেকে gateway পর্যন্ত RTT ৩০ ms, gateway-এর নিজের কাজ ১ ms, ডেটা সেন্টারের ভেতরের RTT ০.৫ ms, BFF-এর নিজের কাজ ৩ ms; সার্ভিসের সময় profile ২০, feed ৪৫, notify ১৫ ms.

একই হিসাব কোডে — চারটি পরিস্থিতি, দুই রকম link-এ। hop বা svc-এর মান বদলে নিজের অনুমান বসাতে পারেন:

// p50-ish latency (ms) of a home screen that needs 3 backend services.
// Every number is an ASSUMED round value for learning, not a measurement.
const hop = { cdn: 1, edgeToGw: 30, gw: 1, bff: 3, dcRtt: 0.5 };  // compute + RTTs
const svc = { profile: 20, feed: 45, notif: 15 };                // service times
const t = Object.values(svc);
const sum = a => a.reduce((x, y) => x + y, 0);

// one API call from the phone: last mile -> CDN edge -> gateway -> one service
const call = (lastMile, s) => lastMile + hop.cdn + hop.edgeToGw + hop.gw + hop.dcRtt + s;
// one trip from the phone to the BFF (same path, plus the BFF's own compute)
const front = lastMile => lastMile + hop.cdn + hop.edgeToGw + hop.gw + hop.dcRtt + hop.bff;

function scenarios(lastMile) {
  return [
    ["app calls 3 APIs one by one", sum(t.map(s => call(lastMile, s))), "3 req, 3 waits"],
    ["app calls 3 APIs in parallel", Math.max(...t.map(s => call(lastMile, s))), "3 req, 1 wait"],
    ["BFF calls services one by one", front(lastMile) + sum(t.map(s => hop.dcRtt + s)), "1 req, 1 wait"],
    ["BFF calls services in parallel", front(lastMile) + Math.max(...t.map(s => hop.dcRtt + s)), "1 req, 1 wait"],
  ];
}
for (const [name, rtt] of [["mobile, last-mile RTT 150 ms", 150], ["broadband, RTT 20 ms", 20]]) {
  console.log("== " + name + " ==");
  for (const [k, ms, phone] of scenarios(rtt))
    console.log(k.padEnd(31) + ms.toFixed(1).padStart(6) + " ms   phone: " + phone);
}
console.log("one extra hop inside the DC: gateway " + (hop.gw + hop.dcRtt) + " ms, BFF " + (hop.bff + hop.dcRtt) + " ms");

== mobile, last-mile RTT 150 ms ==
app calls 3 APIs one by one     627.5 ms   phone: 3 req, 3 waits
app calls 3 APIs in parallel    227.5 ms   phone: 3 req, 1 wait
BFF calls services one by one   267.0 ms   phone: 1 req, 1 wait
BFF calls services in parallel  231.0 ms   phone: 1 req, 1 wait
== broadband, RTT 20 ms ==
app calls 3 APIs one by one     237.5 ms   phone: 3 req, 3 waits
app calls 3 APIs in parallel     97.5 ms   phone: 3 req, 1 wait
BFF calls services one by one   137.0 ms   phone: 1 req, 1 wait
BFF calls services in parallel  101.0 ms   phone: 1 req, 1 wait
one extra hop inside the DC: gateway 1.5 ms, BFF 3.5 ms

ভালো অভ্যাস: একটি ব্যবহারকারী-অভিজ্ঞতার জন্য একটি BFF, প্রতিটি ফোন-মডেলের জন্য নয়; BFF পাতলা — শুধু জোড়া, ছাঁটা আর মানিয়ে দেওয়া; মালিক সেই client-এর দল। আরেকটি পথ GraphQL, যেখানে client নিজেই বলে দেয় কোন field লাগবে; এর trade-off পর্ব ৯-এ।

৭ · Version আর canary routing — নতুন সংস্করণে ধীরে ধীরে

Version routing

API-তে ভাঙনধরা পরিবর্তন এলে নতুন সংস্করণ (API versioning, পর্ব ৮)। Gateway এটি সহজ করে: /v1/orders/ যায় orders-v1-এ, /v2/orders/ orders-v2-এ; কেউ কেউ header দিয়ে version বোঝান। পুরোনো অ্যাপ-সংস্করণ মাসের পর মাস ফোনে থাকে, তাই v1 অনেক দিন বাঁচিয়ে রাখতে হয় — কখনো gateway-এর transformation দিয়ে v1-এর অনুরোধ নতুন সার্ভিসের ভাষায় অনুবাদ করে।

Canary routing — কাদের নতুন সংস্করণে পাঠাবেন

Canary release-এ নতুন সংস্করণ আগে খুব ছোট অংশ পায়। Header দিয়ে: ভেতরের পরীক্ষকদের অ্যাপ একটি নির্দিষ্ট header পাঠায়, gateway তা দেখে v2-তে পাঠায় — তবে শুধু যাচাই করা কর্মী-অ্যাকাউন্টের জন্য। শতাংশ দিয়ে: ব্যবহারকারীর ID থেকে একটি hash বানিয়ে ০ থেকে ৯,৯৯৯-এর একটি bucket; bucket ৫০০-এর কম হলে v2 — প্রায় ৫%.

প্রতিটি অনুরোধে নতুন লটারি নয় কেন? তাহলে একই মানুষ এক মুহূর্তে নতুন পর্দা, পরের মুহূর্তে পুরোনো পর্দা দেখবেন — বিভ্রান্তি, cache-এ গোলমাল, আর অভিযোগ এলে “উনি কোন সংস্করণে ছিলেন?” বলা অসম্ভব। Hash দিলে ভাগটি sticky: একই ID, প্রতিবার একই bucket. ৫% থেকে ২০%-এ বাড়ালে শুধু সীমা ৫০০ থেকে ২,০০০ হয় — আগের সবাই v2-তেই থাকেন। আর প্রতিটি rollout-এর নাম hash-এ মেশানো (salt), যাতে প্রতিবার একই ৫% পরীক্ষার মুখে না পড়েন।

// Canary routing: about 5% of USERS (not requests) go to v2, chosen by a hash of the user ID.
function fnv1a(str) {                        // FNV-1a, 32-bit
  let h = 0x811c9dc5;
  for (let i = 0; i < str.length; i++) h = Math.imul(h ^ str.charCodeAt(i), 0x01000193) >>> 0;
  return h;
}
function mulberry32(a) {                     // small seeded PRNG: same "random" users every run
  return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const bucket = id => fnv1a("home-v2:" + id) % 10000;           // 0..9999, salted per rollout
const version = (id, pct) => (bucket(id) < pct * 100 ? "v2" : "v1");

const rnd = mulberry32(2026), ids = new Set();
while (ids.size < 10000) ids.add("u" + Math.floor(rnd() * 1e9));
const users = [...ids];

const at5 = users.filter(u => version(u, 5) === "v2");
console.log("5% rollout : " + at5.length + " of " + users.length + " users on v2 (" + (at5.length / 100).toFixed(2) + "%)");
for (const u of [users[0], at5[0]])                               // sticky: same user, same answer
  console.log("  " + u.padEnd(11) + "bucket " + String(bucket(u)).padStart(4) + " -> 5 requests: " +
    [1, 2, 3, 4, 5].map(() => version(u, 5)).join(" "));

const at20 = users.filter(u => version(u, 20) === "v2");
const kept = at5.filter(u => version(u, 20) === "v2").length;
console.log("20% rollout: " + at20.length + " users on v2; of the first " + at5.length + ", still on v2: " + kept);

let mixed = 0;                                   // contrast: a fresh coin flip on EVERY request
for (let u = 0; u < users.length; u++) {
  const seen = new Set();
  for (let r = 0; r < 20; r++) seen.add(rnd() < 0.05 ? "v2" : "v1");
  if (seen.size === 2) mixed++;
}
console.log("per-request random, 20 requests each: " + mixed + " users saw BOTH versions");

5% rollout : 497 of 10000 users on v2 (4.97%)
  u455407699 bucket 9625 -> 5 requests: v1 v1 v1 v1 v1
  u1731545   bucket  304 -> 5 requests: v2 v2 v2 v2 v2
20% rollout: 2027 users on v2; of the first 497, still on v2: 497
per-request random, 20 requests each: 6461 users saw BOTH versions

৮ · Gateway-এর নিজের ঝুঁকি — SPOF, bottleneck, latency আর config drift

Single point of failure আর bottleneck

সব অনুরোধ gateway দিয়ে যায় — তাই gateway বন্ধ মানে সব বন্ধ (single point of failure, পর্ব ৫), আর gateway ধীর মানে সব ধীর — bottleneck. প্রতিকারগুলো:

• কয়েকটি instance, কয়েকটি zone-এ: সামনে একটি সরল L4 load balancer বা anycast — একই IP কয়েক জায়গা থেকে ঘোষণা (Computer Networks কোর্সের BGP পর্ব)। L4 স্তর HTTP পড়ে না বলে দ্রুত আর কম ভাঙে; তারও redundancy লাগে (virtual IP, পর্ব ৫)।
• Instance stateless: session নিজের কাছে নয়; quota counter ভাগ করা store-এ (পর্ব ৩০, ৪৯), বা প্রতিটি instance-এ সীমার ভাগ (তিনটি হলে মোটামুটি সীমা ÷ ৩)।
• N+1 সামর্থ্য: একটি instance হারালেও বাকিরা পুরো ভার নিতে পারে; autoscaling-এ নতুন instance আসতে সময় লাগে (পর্ব ১৩)।
• ভিড়ে নিজেকে বাঁচানো: সামর্থ্যের বেশি অনুরোধে দ্রুত 503 — load shedding (পর্ব ১৮)।

একটি instance পড়ে গেলে কী ঘটে, সময় ধরে দেখুন। ধরা যাক: মোট ৩,০০০ RPS, প্রতিটি instance-এর সামর্থ্য ২,০০০ RPS.

প্রতিটি hop-এর দাম

অংশ ৬-এ ভেতরের একটি proxy-hop ধরা হয়েছিল ১.৫ ms, BFF ৩.৫ ms — mobile-এর ১৫০ ms RTT-এর পাশে সামান্য। কিন্তু স্তর জমতে থাকে: CDN → WAF → L4 LB → gateway → BFF → প্রতিটি ভেতরের call-এ দুই পাশে দুটি sidecar. ভেতরে ২০টি call পরপর হলে, প্রতিটিতে দুটি sidecar × ০.৫ ms ধরলেই ২০ ms যোগ হয়; আর p99-এ প্রতিটি proxy নিজের ধীর মুহূর্ত (garbage collection, সারিতে অপেক্ষা) যোগ করে। নিয়ম: প্রতিটি স্তরের পক্ষে একটি নির্দিষ্ট কারণ চাই, আর latency budget-এ (পর্ব ৪) প্রতিটি hop-এর জায়গা।

Config drift — একই gateway, ভিন্ন আচরণ

ছয়টি instance, একটিতে রাত ২টায় হাতে করা “জরুরি” সংশোধন, আরেকটিতে পুরোনো plugin — এখন ফল নির্ভর করে অনুরোধটি কোন instance-এ পড়ল তার ওপর। এর নাম configuration drift; এমন বাগ খোঁজা খুব কঠিন, কারণ বেশিরভাগ চেষ্টায় সমস্যা দেখা দেয় না। প্রতিকার: config git-এ; প্রতিটি পরিবর্তন review আর স্বয়ংক্রিয় পরীক্ষা পেরিয়ে একই artifact হিসেবে সব instance-এ; হাতে বদলানো বন্ধ; চলমান config-এর hash মিলিয়ে drift ধরা; আর config-ও ধাপে ধাপে ছড়ানো। একটি ভুল config একসাথে সব instance-এ গেলে redundancy কোনো কাজে আসে না — এটিই পর্ব ৫-এর correlated failure.

Edge gateway, internal gateway আর service mesh

বাইরে থেকে ভেতরে আসা traffic-কে বলে north-south, ভেতরের সার্ভিস থেকে সার্ভিসে east-west. Proxy বসে তিন জায়গায়:

Sidecar-গুলো মিলে data plane, যারা আসল অনুরোধ বহন করে; control plane তাদের নিয়ম পাঠায়। Service mesh আর service discovery — পর্ব ৪৭ (Monolith বনাম microservices)-এ; Kubernetes-এর Ingress আর mesh-এর নেটওয়ার্ক-দিক Cloud আর container নেটওয়ার্কিং পর্বে।

৯ · AI-এর যুগে gateway-নকশা যাচাই

“Scalable architecture” চাইলে AI প্রায় নিশ্চিতভাবে একটি API gateway, একটি service mesh আর তিন-চারটি নতুন বাক্স বসিয়ে দেয়। এই বিষয়ে কিছু ভুল AI প্রায় নিয়ম করে করে:

AI-এর দেওয়া gateway-নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি proxy-স্তরের পক্ষে একটি নির্দিষ্ট কারণ আছে; কারণ না থাকা স্তর বাদ দিয়েছি
• ব্যবসার নিয়ম আর object-level অনুমতি সার্ভিসে আছে, gateway-এর plugin-এ নয়
• Gateway কয়েকটি stateless instance-এ, N+1 সামর্থ্যসহ; একটি হারালে ক্ষতির হিসাব নিজে করেছি
• Latency নিজে আবার হিসাব করেছি — parallel-এ সবচেয়ে ধীরটি, sequential-এ যোগফল, আর ধীর link-এর RTT সহ
• Config আর পণ্যের সীমা অফিসিয়াল ডকুমেন্টেশনে মিলিয়েছি; syntax পরীক্ষা আর ছোট load test চালিয়েছি