API Gateway - সব request এর একটাই দরজা

০০ যে প্রশ্নগুলোর উত্তর খুঁজবো

সেশন ১১ তে আমরা একটা বড় system কে অনেকগুলো ছোট service এ ভাগ করেছি। সেশন ১২ তে দেখেছি, service গুলো নিজেদের মধ্যে কীভাবে কথা বলে। কিন্তু একটা প্রশ্ন এখনো বাকি। বাইরের দুনিয়া, মানে customer এর mobile অ্যাপ আর browser, এই এতগুলো service এর সাথে কীভাবে কথা বলবে?

এই সেশনে আমরা একজন mobile developer এর পাশে বসবো। তার অ্যাপের login এ প্রায় ৯ সেকেন্ড লাগে। শেষে আপনি বুঝবেন, সব request এর জন্য একটাই দরজা বসালে কেন অ্যাপ দ্রুত হয়, আর system নিরাপদও হয়।

০১ Mobile অ্যাপ সরাসরি ২০টা microservice কে call করলে সমস্যা কোথায়?

রবিবার সকাল। মিতু অফিসে ঢুকে চায়ের কাপটা নামিয়ে রাখতেই Play Store এর একটা review চোখে পড়লো। রংপুরের এক দোকানদার এক তারা দিয়ে লিখেছেন: “Login করতে দশ সেকেন্ড লাগে। Customer দাঁড়িয়ে থাকে, আমি টাকা পাঠাতে পারি না।” মিতু একটা ব্যাংকের mobile অ্যাপের developer। মন খারাপ করে সে নিজের phone টা 3G তে নামিয়ে login করলো। Spinner ঘুরলো প্রায় ৯ সেকেন্ড।

Network log খুলে মিতু অবাক হলো। Login screen শেষ করতে অ্যাপটা ৭টা আলাদা server এ ৭টা call পাঠাচ্ছে। Login, profile, account balance, card, শেষ ৫টা লেনদেন, notification এর সংখ্যা আর offer। প্রতিটা call যায় আলাদা একটা service এ, আলাদা ঠিকানায়।

সমস্যা ১: ধীর network এ প্রতিটা call দামি

3G তে phone থেকে server এ গিয়ে ফিরে আসতে (এক round trip, সংক্ষেপে RTT) প্রায় ৩০০ms লাগে। নতুন একটা server এর সাথে প্রথমবার কথা বলতে শুধু হাত মেলাতেই কয়েকটা round trip চলে যায়। হিসাবটা দেখুন:

# 3G তে একটা round trip (RTT): প্রায় 300 ms

# নতুন একটা host এ প্রথম call
DNS lookup (ঠিকানা খোঁজা): 1 RTT
TCP handshake: 1 RTT
TLS handshake (TLS 1.2): 2 RTT
আসল request + response: 1 RTT
মোট: 5 RTT × 300 ms ≈ 1.5 s

# মিতুর login screen
একটার পর একটা: login, profile, accounts, txn
    4 × 1.5 s ≈ 6.0 s
একসাথে: cards, notify, offers
    ≈ 1.5 s
180 KB JSON নামানো, 3G তে ~125 KB/s
    ≈ 1.4 s
সব মিলিয়ে ≈ 9 s

এখানে handshake মানে আসল কথা শুরুর আগে দুই পক্ষের পরিচয় আর নিয়ম ঠিক করে নেওয়া। TLS হলো সেই ব্যবস্থা, যেটা HTTPS কে encrypted রাখে (সেশনের ০৪ নম্বর অংশে বিস্তারিত)। ৭টা আলাদা host মানে এই handshake ৭ বার। আর কিছু call আগের call এর উত্তরের জন্য অপেক্ষা করে, তাই সেগুলো একটার পর একটা চলে। ৯ সেকেন্ড এভাবেই হয়।

সমস্যা ২: ৭ জায়গায় ৭ রকম token check

একই সপ্তাহে মিতুর inbox এ security audit team এর একটা email এলো। তিন মাস আগে logout করা একজন customer এর পুরোনো token দিয়ে এখনো offer আর notification দেখা যাচ্ছে। কারণ খুঁজতে গিয়ে দেখা গেলো, প্রতিটা service নিজের মতো করে token check করে। কেউ মেয়াদ দেখে, কেউ দেখে না। একটা service তো token খুলে পড়ে, কিন্তু আসল কিনা যাচাইই করে না।

ব্যাংকের দশটা দরজার নয়টায় শক্ত তালা থাকলেও লাভ নেই। চোর খোলা দরজাটাই খুঁজে নেয়।

সমস্যা ৩: অ্যাপ পেছনের সব ঠিকানা জানে

অ্যাপের code এ ৭টা service এর ঠিকানা লেখা আছে। Backend team account-service কে দুই ভাগ করলে অ্যাপও বদলাতে হবে। কিন্তু নতুন version Play Store এ দিলেও সবাই সাথে সাথে update করে না। মাসখানেক পরেও প্রায় ৩০% customer পুরোনো version চালায়। ফলে পুরোনো ঠিকানাগুলো বছরের পর বছর চালু রাখতে হয়।

সমস্যা ৪: সব service internet এ খোলা

অ্যাপ সরাসরি call করে মানে প্রতিটা service কে internet থেকে পৌঁছানো যায়। ২০টা service মানে পাহারা দেওয়ার মতো ২০টা দরজা। প্রতিটার আলাদা certificate, আলাদা firewall rule, আলাদা নজরদারি লাগে।

০২ সব request এর জন্য একটাই দরজা বসালে কেমন হয়?

ব্যাংকের শাখার reception desk

যেকোনো ব্যাংকের শাখায় ঢুকলে কী দেখেন, একবার মনে করুন। ঢোকার দরজা একটাই। দরজায় একজন guard থাকেন। ভেতরে একটা reception desk। আপনি desk এ বলেন, “টাকা জমা দেবো।” উনি দেখিয়ে দেন, “৩ নম্বর counter এ যান।” আপনি নিজে ভল্টে বা manager এর ঘরে ঢুকতে পারেন না। ভেতরের কোন টেবিলে কে বসে, সেটা জানারও দরকার হয় না।

Software এ এই reception desk এর নাম API gateway। এটা একটা server, যেটা সব service এর সামনে দাঁড়িয়ে থাকে। Client এর সব request প্রথমে এখানে আসে। Gateway ঠিক করে, request টা পেছনের কোন service এ যাবে।

Reverse proxy: gateway আসলে কোন জাতের server

Reverse proxy হলো এমন একটা server, যেটা অন্য server গুলোর সামনে দাঁড়ায়। Client ভাবে সে reverse proxy এর সাথেই কথা বলছে। আসলে proxy request টা পেছনের আসল server এ পাঠায়, আর উত্তরটা ফেরত এনে দেয়। Client পেছনের server গুলোকে কখনো দেখে না।

সেশন ০২ এর load balancer ও এক ধরনের reverse proxy। API gateway ও তাই। পার্থক্য হলো, gateway API বোঝে। সে request এর path, header আর token পড়ে সিদ্ধান্ত নেয়। এই পার্থক্য নিয়ে ০৮ নম্বর অংশে আরো কথা হবে।

Routing: কোন request কোথায় যাবে

Gateway এর সবচেয়ে মৌলিক কাজ হলো routing। মানে request এর path দেখে ঠিক service টা বেছে নেওয়া। এর জন্য gateway এর একটা route table থাকে:

# gateway এর route table (সরল উদাহরণ)
routes:
  - match: /auth/*
    upstream: http://auth-service:8080
    auth: none              # login এর আগে token থাকে না
  - match: /accounts/*
    upstream: http://account-service:8080
    auth: jwt
    timeout: 800ms
  - match: /cards/*
    upstream: http://card-service:8080
    auth: jwt
    timeout: 800ms
  # ... বাকি service গুলোর জন্য একই রকম entry

এখন মিতুর অ্যাপ শুধু একটা ঠিকানা চেনে। Backend team পরের মাসে account-service কে দুই ভাগ করলে শুধু gateway এর route table বদলাবে। অ্যাপের একটা লাইনও বদলাতে হবে না, পুরোনো version এর customer রাও কিছু টের পাবেন না।

Gateway কীভাবে জানে account-service এখন কোন machine এ চলছে? সেটা service discovery এর কাজ, সেশন ১৪ তে দেখবো। বাস্তবে gateway হিসেবে Kong, Envoy, NGINX, AWS API Gateway বা Spring Cloud Gateway এর মতো তৈরি software ব্যবহার করা হয়। কেউ শূন্য থেকে নিজে বানায় না।

০৩ Token check প্রতিটা service এ না করে gateway তে একবার করলে কী লাভ?

আগে দুটো শব্দ আলাদা করে নিই, কারণ interview তে এরা প্রায়ই গুলিয়ে যায়।

• Authentication: আপনি কে, সেটা যাচাই করা। Guard আপনার ID card দেখেন।
• Authorization: আপনি এই কাজটা করার অনুমতি পান কিনা, সেটা যাচাই করা। ID ঠিক থাকলেও আপনি অন্যের account থেকে টাকা তুলতে পারেন না।

JWT: সিল দেওয়া একটা digital ID card

মিতু login করলে auth-service তাকে একটা token দেয়। পরের প্রতিটা request এর সাথে অ্যাপ এই token টা পাঠায়। ব্যাংকের অ্যাপে এই token সাধারণত একটা JWT (JSON Web Token)।

JWT কে অফিসের ID card এর মতো ভাবুন। Card এ আপনার নাম আর ID লেখা থাকে। সাথে HR এর একটা সিল থাকে, যেটা নকল করা যায় না। Guard আপনাকে চেনেন না, কিন্তু সিলটা চেনেন। সিল ঠিক থাকলে তিনি card এর লেখা বিশ্বাস করেন। কাউকে ফোন করে জিজ্ঞেস করতে হয় না।

# JWT = header.payload.signature  (তিনটা অংশ, মাঝে ডট)
eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ1XzQ4MjEzIn0.<signature>

# header (decode করলে)
{ "alg": "RS256" }

# payload (decode করলে): যে কেউ পড়তে পারে, তাই গোপন কিছু রাখা যাবে না
{
  "sub":  "u_48213",        # কোন customer
  "role": "customer",
  "iss":  "auth-service",   # কে বানিয়েছে
  "iat":  1762500000,       # কখন বানানো
  "exp":  1762500300        # কখন মেয়াদ শেষ (৫ মিনিট পরে)
}

# signature
auth-service এর private key দিয়ে header আর payload কে sign করা।
Gateway শুধু public key দিয়ে মিলিয়ে দেখে। Public key দিয়ে নতুন token বানানো যায় না।

একটা JWT এর তিনটা অংশ থাকে, মাঝে ডট দিয়ে আলাদা করা:

• Header: কোন পদ্ধতিতে sign করা হয়েছে।
• Payload: customer কে, তার role কী, token কখন বানানো আর কখন মেয়াদ শেষ (exp)।
• Signature: auth-service এর গোপন private key দিয়ে বানানো সিল। Gateway একটা public key দিয়ে সিলটা মিলিয়ে দেখে। Public key দিয়ে সিল যাচাই করা যায়, কিন্তু নতুন সিল বানানো যায় না।

একটা জরুরি সতর্কতা। Payload encrypted নয়, শুধু একটা encoding (base64) করা। যে কেউ এটা খুলে পড়তে পারে। তাই JWT এর ভেতরে কখনো PIN, password বা account এর গোপন তথ্য রাখবেন না।

Edge এ একবার check, মানে gateway তে

এখন token check হয় শুধু gateway তে, একটাই code দিয়ে:

এখানে “edge” মানে system এর বাইরের সীমানা, যেখানে internet শেষ হয়ে আমাদের network শুরু। সেশন ০৬ এর CDN edge এর সাথে মিলটা খেয়াল করুন: দুটোই বাইরের দুনিয়ার সবচেয়ে কাছের জায়গা।

এর লাভগুলো দেখুন। Audit team যে ভুলটা পেয়েছিলো, সেটা আর হওয়ার উপায় নেই, কারণ মেয়াদ check এখন একটাই জায়গায় লেখা। ভুল token ভেতরে ঢোকেই না, তাই service গুলোর CPU সেটার পেছনে নষ্ট হয় না। আর নতুন service বানানোর সময় কাউকে token এর code নতুন করে লিখতে হয় না।

JWT এর একটা দুর্বলতা: মেয়াদের আগে বাতিল করা কঠিন

Gateway কাউকে জিজ্ঞেস না করেই JWT বিশ্বাস করে। এটাই এর গতি, আবার এটাই দুর্বলতা। Customer logout করলেও token এর মেয়াদ শেষ না হওয়া পর্যন্ত সেটা কাজ করে। তাই ব্যাংকের মতো জায়গায় দুটো কাজ করা হয়:

• ছোট মেয়াদ: JWT এর মেয়াদ রাখা হয় ৫ থেকে ১৫ মিনিট। মেয়াদ শেষ হলে অ্যাপ একটা আলাদা, লম্বা মেয়াদের refresh token দিয়ে চুপচাপ নতুন JWT নিয়ে নেয়।
• বাতিলের তালিকা: logout বা চুরি যাওয়া token এর ID একটা ছোট তালিকায় (যেমন Redis এ) রাখা হয়। Gateway প্রতিটা request এ তালিকাটা দেখে নেয়। এটাও এখন এক জায়গাতেই করতে হয়।

০৪ HTTPS এর encryption কোথায় খোলা উচিত?

মিতুর অ্যাপ থেকে ব্যাংক পর্যন্ত data যায় public Wi-Fi, মোবাইল operator আর আরো অনেকের network পার হয়ে। পথে কেউ যেন password বা balance পড়তে না পারে, সেজন্য সব কিছু encrypted থাকে। এই encryption এর ব্যবস্থার নাম TLS (Transport Layer Security)। HTTPS এর “S” টা এটাই।

Encrypted data কোথাও না কোথাও খুলতে হয়, নইলে server request টা পড়বে কীভাবে? যে জায়গায় encryption খোলা হয়, তাকে বলে TLS termination। Gateway থাকলে সাধারণত সেখানেই এটা করা হয়:

Gateway এ TLS termination করার চারটা কারণ:

1. Gateway কে request পড়তেই হয়: path না পড়লে routing হয় না, token না পড়লে JWT check হয় না। Encrypted request এর ভেতরে সে কিছুই দেখতে পায় না।
2. Certificate থাকে এক জায়গায়: TLS এর জন্য একটা certificate লাগে, যেটার মেয়াদ নির্দিষ্ট সময় পর শেষ হয়। ২০টা service এ ২০টা certificate মানে ২০টা মেয়াদের তারিখ মনে রাখা। একটা ভুলে গেলে রাতের বেলা হঠাৎ card section বন্ধ। এখন renew করতে হয় একটাই।
3. Service গুলোর CPU বাঁচে: encryption খোলার কাজে CPU লাগে। এই কাজ এখন gateway একাই করে।
4. Connection একবারই: অ্যাপ gateway এর সাথে একবার handshake করে connection টা খোলা রাখে। পরের সব request সেই connection দিয়েই যায়। আর gateway এ নতুন TLS 1.3 চালু করলে handshake ২ round trip থেকে নেমে ১ round trip হয়, 3G তে যেটা আরো ৩০০ms বাঁচায়।

Gateway এর পেছনে, private network এর ভেতরে, কী হয়? সাধারণ কোম্পানিতে সেখানে plain HTTP চলে, কারণ বাইরের কেউ সেই network এ ঢুকতে পারে না। কিন্তু ব্যাংকের নিয়ম সাধারণত আরো কড়া। সেখানে ভেতরেও আবার encrypt করা হয়, আর দুই পক্ষই নিজের certificate দেখায়। একে বলে mTLS (mutual TLS)। সেশন ১২ এর service mesh এই কাজটা প্রতিটা service এর পাশে বসে নিজে থেকেই করে দেয়।

০৫ Gateway আর কোন কাজগুলো সবার হয়ে করতে পারে?

একটা নিয়ম মনে রাখুন। যে কাজ প্রতিটা service কে একই ভাবে করতে হয়, সেটা gateway তে যাওয়ার প্রার্থী। এমন কাজকে বলে cross-cutting concern। এখানে আরো দুটো দেখি।

Rate limiting: একজনকে কতবার আসতে দেবো

এক রাতে মিতুর team দেখলো, একটা bot একটা phone number দিয়ে মিনিটে ১,০০০ বার login এর চেষ্টা করছে। সে PIN আন্দাজ করার চেষ্টা করছে। Rate limiting মানে একজন client নির্দিষ্ট সময়ে কতগুলো request পাঠাতে পারবে, তার একটা সীমা বেঁধে দেওয়া।

Gateway তে একটা নিয়ম বসানো হলো: একটা phone number দিয়ে মিনিটে ৫ বারের বেশি login চেষ্টা চলবে না। ৬ষ্ঠ চেষ্টায় gateway নিজেই 429 Too Many Requests ফেরত দেয় (সেশন ০৮ এ এই code দেখেছেন)। Bot এর ৯৯৫টা request auth-service পর্যন্ত পৌঁছায়ই না।

Gateway এ এটা করার সুবিধা হলো, সব request এখান দিয়েই যায়। তাই গোনাটা সহজ, আর প্রতিটা service কে আলাদা করে গুনতে হয় না। গোনার নানা পদ্ধতি আছে (token bucket, sliding window ইত্যাদি)। সেগুলো ছবিসহ সেশন ২১ এ দেখবো।

Response caching: একই উত্তর বারবার না বানানো

মিতুর অ্যাপের home screen এ আজকের ডলার রেট দেখায়। সকাল ৯টা থেকে ১০টার মধ্যে প্রায় ৫০,০০০ customer অ্যাপ খোলেন। মানে fx-service এক ঘণ্টায় ৫০,০০০ বার একই প্রশ্নের একই উত্তর দেয়। অথচ রেট বদলায় দিনে বড়জোর কয়েকবার।

Gateway উত্তরটা ৬০ সেকেন্ডের জন্য নিজের কাছে রেখে দিতে পারে। এই ৬০ সেকেন্ডই হলো TTL (সেশন ০৪ এ দেখেছেন)। তখন ঘণ্টায় fx-service এর কাছে যায় মাত্র ৬০টা request, বাকি সব উত্তর gateway থেকেই যায়।

একটা request এর পুরো যাত্রা

এতক্ষণ যা দেখলাম, সব এক ছবিতে রাখলে gateway এর ভেতরে একটা request এর পথ এমন দেখায়:

০৬ ৭টা call কে কি একটা call বানানো যায়?

Gateway বসানোর পর মিতুর অ্যাপে এখন handshake হয় একবারই। কিন্তু অ্যাপ তো এখনো ৭টা request পাঠায়, আর প্রতিটা ধীর 3G পথ পার হয়। মিতু ভাবলো, home screen এর জন্য যা যা লাগে, gateway কি নিজেই সেগুলো জোগাড় করে একবারে দিতে পারে না?

পারে। এই কৌশলের নাম request aggregation। Client একটা request পাঠায়। Gateway ভেতরে কয়েকটা service কে call করে, উত্তরগুলো জোড়া লাগায়, আর একটা উত্তর ফেরত দেয়।

এই কৌশল কাজ করে, কারণ দুই জায়গার network এর গতি একেবারে আলাদা। 3G তে একটা round trip ৩০০ms। Data center এর ভেতরে দুই machine এর মধ্যে round trip ১ms এর মতো। মানে ধীর পথটা যত কম পার হওয়া যায়, তত লাভ।

আরেকটা সুবিধা আছে। আগে account-service কে call করতে অ্যাপকে profile এর উত্তর থেকে customer ID নিতে হতো। এখন customer ID তো JWT এর ভেতরেই আছে। তাই gateway কারো জন্য অপেক্ষা না করে ৬টা call একসাথে পাঠাতে পারে।

একটা service ধীর বা down হলে

ধরুন offer-service সেদিন down। আগে অ্যাপের পুরো home screen error দেখাতো। এখন gateway প্রতিটা ভেতরের call এ একটা timeout রাখে, ধরুন ৩০০ms (timeout কেন প্রতিটা call এ দরকার, সেশন ১২ তে দেখেছেন)। Offer এর উত্তর সময়মতো না এলে gateway বাকি ৫টা উত্তর দিয়েই screen পাঠিয়ে দেয়। Offer এর জায়গাটা শুধু ফাঁকা থাকে। Balance আর লেনদেন ঠিকই দেখা যায়।

এভাবে কম জরুরি অংশ বাদ দিয়ে বাকিটা দেখানোকে বলে graceful degradation। Service বারবার fail করলে তাকে কিছুক্ষণ call করাই বন্ধ রাখার কৌশল (circuit breaker) সেশন ২১ এ আসবে।

০৭ Mobile আর web এর দরকার আলাদা হলে কী করবো?

Aggregation এর সাফল্য দেখে web banking team ও gateway তে নিজেদের home endpoint চাইলো। কিন্তু তাদের দরকার একেবারে অন্য রকম। বড় screen এ তারা দেখায় শেষ ৫০টা লেনদেন, খরচের chart আর পুরো statement। মিতুর অ্যাপে দরকার শুধু শেষ ৫টা লেনদেন আর ছোট একটা balance card।

একটাই endpoint দিয়ে দুজনকে খুশি করতে গেলে code এ if (mobile) এর ছড়াছড়ি হয়। আর দুই team একই file নিয়ে প্রতি সপ্তাহে টানাটানি করে। মিতুর একটা ছোট বদলের জন্য web team এর review লাগে, web team এর deploy এ মিতুর অ্যাপ ভেঙে যায়।

সমাধান হলো BFF (Backend for Frontend)। প্রতিটা ধরনের client এর জন্য একটা করে নিজস্ব ছোট backend। Mobile এর জন্য একটা, web এর জন্য আরেকটা। যে team client বানায়, সেই team ই তার BFF এর মালিক।

খেয়াল করুন, BFF আসলে aggregation ই করে। পার্থক্য হলো, প্রতিটা BFF শুধু একটা client এর কথা ভাবে। Mobile BFF জানে 3G ধীর, তাই সে ছোট উত্তর পাঠায়: ১৫ KB। Web BFF জানে broadband আছে, তাই সে chart এর data সহ ২২০ KB পাঠায়। সাধারণ কাজগুলো (TLS, JWT, rate limit) তখনো সবার জন্য একটাই gateway তে থাকে।

BFF এর downside ও আছে। দুটো BFF এ কিছু code দুইবার লেখা হয়। আর প্রতিটা screen এর জন্য একটা করে BFF বানালে সেটা আবার বিশৃঙ্খলা তৈরি করে। নিয়মটা হলো: একটা BFF প্রতিটা সত্যিকারের আলাদা অভিজ্ঞতার জন্য (mobile, web, হয়তো smartwatch), প্রতিটা screen এর জন্য নয়।

০৮ API gateway আর load balancer কি একই জিনিস?

না। দুটোই reverse proxy, আর দুটোই সামনে দাঁড়িয়ে request ভাগ করে দেয়। কিন্তু দুজন request এর ভেতরটা কতটা বোঝে, সেখানেই পার্থক্য।

সেশন ০২ এর load balancer কে পোস্ট অফিসের বাছাইকারীর মতো ভাবুন। সে দেখে কোন কর্মী ফাঁকা, আর চিঠিটা তার হাতে দেয়। চিঠির ভেতরে কী লেখা, সেটা পড়ে না। Gateway হলো ব্যাংকের reception desk। সে আপনার কাগজ পড়ে, ID দেখে, তারপর ঠিক counter এ পাঠায়।

বাস্তবে দুটো একসাথে থাকে। Gateway এর সামনে একটা load balancer থাকে, যেটা কয়েকটা gateway copy এর মধ্যে traffic ভাগ করে। আর gateway এর পেছনে প্রতিটা service এর কয়েকটা copy এর মধ্যেও load ভাগ হয়। পরের অংশের ছবিতে এটা দেখবো।

০৯ সব traffic gateway দিয়েই যায়। তাহলে gateway down হলে কী হবে?

ঠিক এই প্রশ্নটাই মিতুর team lead প্রথম meeting এ করেছিলেন। উত্তরটা অস্বস্তিকর। একটা মাত্র gateway থাকলে সেটা down হলে ব্যাংকের পুরো অ্যাপ বন্ধ। পেছনের ২০টা service সুস্থ থাকলেও কেউ তাদের কাছে পৌঁছাতে পারবে না। মানে gateway হয়ে যায় SPOF (single point of failure), যেটা সেশন ০১ এ দেখেছেন।

ভালো খবর হলো, সমাধানটা আপনার চেনা:

• Gateway কে stateless রাখুন: JWT check এর জন্য কোনো database লাগে না, public key দিয়েই হয়ে যায়। তাই কোনো gateway copy নিজের ভেতরে কিছু মনে রাখে না। যেকোনো copy যেকোনো request সামলাতে পারে (stateless এর ধারণা সেশন ০২ তে দেখেছেন)।
• কয়েকটা copy, আলাদা zone এ: zone মানে একই শহরের আলাদা data center, আলাদা বিদ্যুৎ আর network সহ। একটা zone এ বিদ্যুৎ গেলেও অন্য zone এর gateway চলতে থাকে।
• সামনে load balancer: load balancer heartbeat দিয়ে দেখে কোন gateway সুস্থ। একটা down হলে তাকে বাদ দিয়ে বাকিদের কাছে traffic পাঠায়।
• ভাগ করা হিসাব আলাদা জায়গায়: rate limit এর গোনা প্রতিটা copy নিজে রাখলে তিনটা copy মিলে একজনকে মিনিটে ৫ এর বদলে ১৫ বার ঢুকতে দেবে। তাই এই হিসাব রাখা হয় সবার জন্য একটা Redis এ।
• Config সাবধানে বদলান: একটা ভুল route rule এক মুহূর্তে সব service এর পথ বন্ধ করতে পারে। তাই নতুন config আগে একটা copy তে চালিয়ে কয়েক মিনিট দেখা হয়, তারপর সবগুলোতে।

Gateway কে হালকা রাখুন

সবচেয়ে বড় প্রলোভন হলো gateway তে business logic ঢোকানো। “Transfer এর সীমা ৫০,০০০ টাকা, এটা gateway তেই check করে ফেলি।” এভাবে একটা একটা করে নিয়ম ঢুকলে কিছুদিন পর সব team একই gateway তে code লেখে, একই দিনে deploy এর জন্য লাইনে দাঁড়ায়। সেশন ১১ তে যে monolith ভেঙে বেরিয়ে এসেছিলেন, সেটাই gateway এর ভেতরে নতুন করে জন্ম নেয়।

Gateway তে রাখুন শুধু সেই কাজ, যা সবার জন্য একই: routing, TLS, JWT check, rate limit, cache। ব্যাংকের নিয়ম থাকুক service এর ভেতরে।

তিন মাস পর মিতু আবার 3G তে login করে দেখলো। Home screen এলো প্রায় ২ সেকেন্ডে। রংপুরের সেই দোকানদার review টা বদলে চার তারা দিয়েছেন। আর audit team এর ticket বন্ধ হয়েছে একটা লাইনের উত্তরে: “Token check এখন একটাই জায়গায় হয়।“

১০ মগজে প্রেশার দিন

আগে নিজে ভাবুন। তারপর দেখুন: সবাই যেভাবে ভাবে, সেটা কোথায় অসম্পূর্ণ, আর আসল কথাটা কোথায়।

১১ যে টার্মগুলো শিখলাম

১২ শর্ট সামারি

১৩ মনে রাখুন

• Client একটাই ঠিকানা চিনবে। পেছনের service ভাগ হোক বা নাম বদলাক, অ্যাপের কিছু বদলাতে হবে না।
• ধীর network এ round trip এর সংখ্যাই আসল খরচ। ৩০০ms এর ৭টা পথের চেয়ে ৩০০ms এর একটা পথ আর ১ms এর ৬টা পথ অনেক সস্তা।
• Authentication gateway তে, authorization service এ। Gateway বলে আপনি কে, service ঠিক করে আপনি কী পাবেন।
• JWT এর payload যে কেউ পড়তে পারে। তাই এর ভেতরে কখনো গোপন কিছু রাখবেন না, আর মেয়াদ ছোট রাখুন।
• ব্যক্তিগত data shared cache এ নয়। Gateway তে শুধু সবার জন্য একই উত্তর cache করুন।
• Gateway হলো reception desk, ব্যাংকের manager নয়। সবার জন্য একই কাজ এখানে রাখুন, business rule রাখুন service এ।
• একটা gateway মানে একটা SPOF। কয়েকটা stateless copy আলাদা zone এ চালান, সামনে load balancer রাখুন।