DEV Community: Monirul Islam

Day 29 — Observability: Logs, Metrics, Traces — Production-এর তিন চোখ

Monirul Islam — Sun, 04 Oct 2026 04:20:00 +0000

আপনার application এখন আরামে চলছে। Engineering team-ও একটু শান্তিতে আছে। এখন আর তাদের বেশি প্যারা নিতে হচ্ছে না। এত কিছু হওয়ার পরেও একটা জিনিস বাকি রয়ে গেছে। আপনার application-এর বয়স অনেক দিন হয়ে গেল। কিন্তু আপনাকে যদি জিজ্ঞেস করা হয় গত ১ মাসে আপনার application-এর user-এর সংখ্যা কেমন ছিল, বা ৭ দিনের? এই প্রশ্নের উত্তর আপনি এখন শুধু অনুমান করে বলতে পারবেন। Exactly কোনো data নেই।

আপনি এখন microservice architecture-এ আছেন। এখন অনেকগুলো server হয়ে গেছে। একটা service-এর জন্য multiple region-এ multiple server রয়েছে। এই serverগুলো কখন কী হচ্ছে, কোন server-এর জন্য usage কেমন, তাদের uptime record কেমন, কোনো error face করছে কিনা—এগুলো কিন্তু real-time-এ দেখার কোনো ব্যবস্থা আপনার কাছে নেই।

আরেকটা situation বলি, আপনার engineering team খুব ভালো ভাবে testing করেছে + test case লিখে রেখেছে, সেগুলো test হয়েছে। CI/CD pipeline-এ হয়েছে। এ ছাড়াও একটা systematic way-তে engineering team এমন ব্যবস্থা করেছে যে, যাই হয়ে যাক application-এ কোনো error হলে server crash করবে না। কিন্তু testing environment আর production—২টা জিনিস একেবারেই আলাদা। কখন কোন সময় কী issue হবে আপনি বলতে পারবেন না। For example, এমন একটা error হলো (rare error), error যেহেতু handle হয়েছে সেহেতু server crash করবে না। আর আপনিও বুঝতে পারবেন না যে কোনো error হয়েছে। আর আপনি বুঝতে না পারলে error solve হবে না। একটা সময় এই error-ই আপনার system crash-এর কারণ হয়ে যেতে পারে। এখন প্রশ্ন হচ্ছে এটা কীভাবে prevent করবেন?

এই situation handle করার জন্য মূলত ময়দানে আসে Observability। এর মাধ্যমে আপনার application-এর যাবতীয় information real-time-েই দেখতে পারবেন।

Observability-র তিনটা Pillar

Logs

একটা জিনিস খেয়াল করবেন, বড় building + office-এর gate-এ একজন guard থাকেন যিনি building-এ কে entry নিচ্ছে আর কে building থেকে বাইরে যাচ্ছে সব কিছুর record রাখছেন। এইটা রাখার মূল কারণ হচ্ছে যদি কোনো incident হয় তাহলে এটা helpful হবে। এই entryগুলোই হচ্ছে logs।

Similar way-তে application-এ কে access করছে, কী access করছে, তাকে কী response দেওয়া হয়েছে, কোনো error হয়েছে কিনা, কী error হয়েছে—এই সবকটি জিনিস store করে রাখা হয় যাতে পরে এগুলো analysis করা যায়।

মূলত এই logs-এর মাধ্যমেই application level error + bug-এর solution করা হয়ে থাকে। অনেক ক্ষেত্রে infrastructure related errorগুলোও এই logs analysis করার মাধ্যমে বের করা যায়।

Metrics

এইটা log-এর মতোই, তবে এটা infrastructure level-এ কাজ করে। যেমন সার্ভার কতগুলো, তাদের CPU, memory usage কেমন, তারা কেমন user serve করছে, তাদের health কেমন, কোনো fault আছে কিনা—এই সব কিছু metrics-এর মাধ্যমে বের করা যায়।

Traces

একটা গল্প বলি, আপনি নিশ্চয়ই কোনো গুপ্তধন খোঁজার রহস্যের গল্প পড়েছেন অথবা movies-এ দেখেছেন। ওখানে একটা জিনিস খেয়াল করবেন যে একটা ছোট information decode করে step-by-step ওই গুপ্তধনের কাছে পৌঁছে যায়। এই যে step-by-step, একটা জিনিস থেকে অন্য একটা জিনিসে যাওয়ার history-টাই হচ্ছে traces।

অনেক সময় application-এ কোনো একটা request কোন layer (services) হয়ে গেছে তা জানার প্রয়োজন হয়। এই জন্য প্রতিটা request-এর history store করার প্রয়োজন হয়। Tracing-টা সব থেকে বেশি কাজে লাগে যখন কোনো error হয়। একটা error আসলে কোনো service-এর কোনো file-এর কারণে হয়েছে তা এই tracing-এর মাধ্যমে easily identify করা যায়।

Structured Logging

অগোছালো জিনিস নিয়ে কাজ করা একটু ঝামেলার, process করতে অনেক problem face করা লাগে + output properly generate করা possible না। এখন আপনি যদি logsগুলো অগোছালোভাবে store করেন তাহলে সেখান থেকে data output generate করা tough। এই জন্য structured way-তে log store করা দরকার। এই structured dataগুলো সব predictable, এই জন্য আপনি চাইলেই processing-এর জন্য একটা program লিখে রাখতে পারেন।

// ❌ এটা search করা কঠিন
console.log(`User 5 placed order 123 at ${new Date()}`);

// ✅ এটা search, filter, aggregate করা যায়
logger.info("Order placed", {
  userId: 5,
  orderId: 123,
  amount: 1500,
  timestamp: new Date().toISOString(),
  requestId: req.headers["x-request-id"],
});

Structured log মানেই হচ্ছে JSON। JSON data-এর ওপর easily query করা যায়।

Logging-এর জন্য অনেক ধরনের tool আছে, for example: Elasticsearch, CloudWatch, Loki ইত্যাদি। এগুলো dynamically আপনার করা logsগুলো store করে সেখান থেকে process করবে। এই সব toolগুলো default ভাবেই JSON data parse করতে পারে।

Log Levels

logger.error("Payment failed", { error, userId }); // Alert দরকার
logger.warn("High memory usage", { usage: "85%" }); // নজরে রাখো
logger.info("Order created", { orderId }); // Normal flow
logger.debug("Cache miss", { key }); // Dev only

Log level-টা error বা bug resolve করার জন্য খুবই কাজে লাগে। একটা application যেখানে ১ মিলিয়ন user আছে সেখানে যদি সব log-ই সেম থাকে তাহলে আপনাকে error খুঁজতে বেগ পেতে হবে। আর logging toolগুলো কিছুই করতে পারবে না।

Suppose আপনি application-এ কী কী error encounter হয়েছে সেগুলো দেখতে চাচ্ছেন, তখন আপনি just error log level দিয়ে filter করলেই error related সবগুলো পেয়ে যাবেন। Proper way-তে log level maintain করলে log analysis করা easy হয়ে যায়।

একটা জিনিস, debug level-টা শুধুমাত্র dev environment-এর জন্য use করবেন। Production-এ যেন এই debug level-টা off করা থাকে, না হয় অনেক unnecessary log store হয়ে যাবে।

Metrics

Production-এ CPU, memory, response time, active user count — এই সংখ্যাগুলো সবসময় monitoring-এর মধ্যে রাখা হয়।

// Prometheus metrics
const httpRequestDuration = new Histogram({
  name: "http_request_duration_seconds",
  help: "HTTP request duration",
  labelNames: ["method", "route", "status_code"],
  buckets: [0.1, 0.5, 1, 2, 5],
});

Dashboard-এ দেখতে পাবেন —

প্রতি সেকেন্ডে কতটা request আসছে
Average response time
Error rate
DB connection pool usage

Grafana + Prometheus use করে এই টাইপের dashboard easily বানানো যায়। In fact অনেক existing template আছে, চাইলে সেগুলোও use করা যেতে পারে।

Distributed Tracing: Request-এর পুরো যাত্রা

এই জিনিসটা একটা Nightmare। আপনি যখন Microservices Architecture + Multiple region-এ support দেন তখন by default "API Gateway", "Load Balancer" এই জিনিসগুলো চলে আসে। Similar type-এর অনেক জিনিসপত্র এখানে use হওয়াটা নরমাল ব্যাপার। একটা request কোথায় কোথায় যাচ্ছে, কোন কোন layer দিয়ে যাচ্ছে, কত time নিচ্ছে—এই জিনিসগুলোর trace রাখাটা দরকার। System optimize করার ক্ষেত্রে এগুলো কাজে লাগে।

For example, আপনার application-এর জন্য Asia + Europe, দুই জায়গায় server আছে। কিন্তু Asia থেকে request গেলে তার latency অনেক বেশি হচ্ছে, কিন্তু Europe-এর টা ঠিকই আছে। এই ক্ষেত্রে আপনি কীভাবে বিষয়টাকে deal করবেন?

এই distributed tracing-এর মাধ্যমে আপনি জানতে পারেন, Asia থেকে যে requestগুলো যাচ্ছে সেগুলো সব America-তে থাকা server থেকে response আসছে। আরেকটু analysis করার পরে বুঝতে পারলেন যে load balancer এই কাজটা করছে। এখন আপনি কিন্তু latency বেশি হওয়ার reason-টা জানেন। এই problem solve করা আপনার জন্য খুব বেশি problem হবে না।

Standard Tool: OpenTelemetry (OTel)

Distributed Tracing implementation জন্য বর্তমান industry gold standard হলো OpenTelemetry (OTel)।

আগে ডেটা কালেক্ট করার জন্য একেক টুলের (Datadog, New Relic, Jaeger) আলাদা আলাদা লাইব্রেরি দিয়ে কোড instrument করতে হতো, যার ফলে অন্য কোনো vendor switch করা অত্যন্ত কঠিন ছিল (Vendor Lock-in)।

OpenTelemetry এই সমস্যার সমাধান করে:

Vendor-Neutral: কোডে একবার OTel SDK দিয়ে trace/metrics/logs বসাবেন, এরপর কনফিগারেশন চেঞ্জ করে Jaeger, Prometheus বা যেকোনো cloud provider-এ পাঠাতে পারবেন; কোড পরিবর্তন করতে হবে না।
Context Propagation: microservice-এর একটি service যখন অন্য service-কে কল করে তখন OTel automatically HTTP হেডার দিয়ে traceparent (Trace ID এবং Span ID) পাস করে দেয়। ফলে পুরো request journey-এর প্রতিটি স্টেপ একটি একক সূত্রে গেঁথে যায়।

Alerting: ঘুম থেকে তুলবে

ছোটবেলায় যখন কোনো মিশন (আপনি জানেন কী mean করছি) করতে যেতাম, তখন ১ জনকে পাহারা দিতে বলতাম। তাকে বলা ছিল যে, যদি কেউ ধারের কাছে আসে তাহলে আমাদেরকে একটা sound দিয়ে জানিয়ে দিবি, আমরা safe zone-এ চলে যাব। আসলে ওই ১ জন ছিল আমাদের alerting system।

Application-এর ক্ষেত্রে এই alerting প্রয়োজন। এই alerting system-এর threshold set করা রাখতে হবে আর সেটা check হবে metrics-এর মাধ্যমে। Threshold cross করলেই alert দেবে।

বটম লাইন

Production system মানে অন্ধকারে কাজ না। Logs, Metrics, Traces — এই তিনটা ঠিকঠাক থাকলে যেকোনো incident দ্রুত diagnose করা যায়। Observability-তে invest করা কোনো luxury না। এটা professional software engineering-এর requirement।

Day 28 — CI/CD Pipeline — Commit থেকে Production পর্যন্ত নিরাপদে যান

Monirul Islam — Sat, 03 Oct 2026 04:20:00 +0000

এতদিন তো অনেক কিছুই করলেন কিন্তু এখনো বেশ কিছু জায়গা আছে যেগুলোতে productivity একটু হলেও বাড়াতে পারেন। এবার আপনি development workflow-টাকে একটু optimize করার কথা চিন্তাভাবনা করলেন। এটা মাথায় রেখে আপনি প্রত্যেকটা team-এর workflow analysis করতে বসলেন।
এখানে আপনি অনেকগুলো জিনিস লক্ষ্য করলেন। বিশেষত অনেকগুলো কাজ আছে যেগুলো প্রতিদিন repeatedly করতে হয়। সেগুলো হলো:

১. manually code test করা লাগে।
২. কোনো feature add হলে সেটা build করে, deploy করতে হয়।
৩. manually test করার কারণে, production-এ যেয়ে অনেক unwanted error দেখা দেয় সেগুলোও solve করা লাগে।

এছাড়াও এই repeated কাজ করতে করতে team member-রা bore হয়ে যাচ্ছে। তারা কিছু বলছে না কারণ তাদেরকে proper সুযোগ-সুবিধা দেয়া হচ্ছে এর জন্য। না হলে company থেকে চলে যেত।

উপরে যে repeated task-গুলো রয়েছে, সেগুলো docker এবং k8s introduce করার পর একটু কমে গেছে। আগে অনেক কিছু করা লাগত। এখন docker image build বা k8s deployment use করলেই কাজ শেষ।

এর পরের বিষয়গুলো তারপরও repeated কাজ। এগুলো automatic করা যায় কি না। তো আপনার মাথায় একটা idea আসল যে, এই কাজগুলো তো same, আপনি যদি একটা shell script লিখে ফেলেন তো কাজ হয়ে যাবে। shell script দিয়ে প্রথমে testing করার জন্য test-গুলো run করবো, then সেটাকে build করার দরকার হলে build করে দেখবো যে কোনো error আছে কি না, and finally সেটাকে deploy করে দেবো।

এটাকেই বলে CI/CD (Continuous Integration/Continuous Delivery)

CI vs CD

CI (Continuous Integration) — প্রতিটা code push-এ automatically test run করা, build করা হয়। মূলত চেকিং এর কাজ টা এই step এ হয়। কোনো problem হলে সেটা সাথে জানাবে এবং সামনের দিকে আগাবে না।

CD (Continuous Delivery) — CI পাস করলে staging-এ automatically deploy হয়ে যাবে।

CD (Continuous Deployment) — Production-এ auto deploy। Human approval নেই।

বেশিরভাগ team Continuous Delivery করে — staging auto deploy হয় আর production-এ একজন approve করলে তারপর deploy হয়।

GitHub Actions: সহজ শুরু

এখন আপনি একটা shell scripting করে আপনার একটা workflow automate করতে পারবেন। shell scripting আপনার একার জন্য একদম ঠিক আছে, কিন্তু আপনার company-তে team অনেক বেশি, অনেক manpower রয়েছে। আপনার style আর তাদের style-টা নাই match হতে পারে। তখন আবার complication বাড়বে। এর জন্য standard কিছু জিনিস দরকার। তবে একটা CI/CD-এর ক্ষেত্রে কোনো fixed standard নেই।
এই standard-তো complication দূর করার জন্য আপনি নানারকমের tool use করতে পারেন। GitHub Actions is one of them।

নিচে একটা simple CI/CD pipeline লেখা আছে। দেখলে কিছুটা idea পাবেন।

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Run tests
        run: npm run test:ci

      - name: Build
        run: npm run build

GitHub Actions GitHub-এ run হয়। উপরের এই workflow-তে বলা হচ্ছে, যখন main branch-এ কোনো কিছু push করা হবে বা pull request create করা হবে তখন নিচের এই job-গুলো হবে। job-এর name-গুলো দেখলেই বুঝতে পারবেন যে এখানে development environment setup করে, প্রথমে linting, then testing and finally build করেছে। এখানে কোনো step-এ যদি কোনো error হয় তাহলে immediately তা stop হয়ে যাবে।

Docker Build + Push

build-and-push:
  runs-on: ubuntu-latest

  steps:
    - uses: actions/checkout@v4

    - name: Build Docker image
      run: docker build -t my-app:${{ github.sha }} .

    - name: Push to registry
      run: |
        docker tag my-app:${{ github.sha }} ghcr.io/myorg/my-app:${{ github.sha }}
        docker push ghcr.io/myorg/my-app:${{ github.sha }}

এখানে simply docker image build and push করা হয়েছে।

Deploy to Production

deploy:
  needs: build-and-push
  runs-on: ubuntu-latest
  environment: production # manual approval লাগবে
  permissions:
    id-token: write # OIDC authentication-এর জন্য
    contents: read

  steps:
    - uses: actions/checkout@v4

    # 1. AWS/GCP/Azure-এর সাথে নিরাপদ OIDC কানেকশন (কোনো permanent secret ছাড়া)
    - name: Authenticate with Cloud Provider (OIDC)
      uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy-role
        aws-region: us-east-1

    - name: Get K8s Context
      run: aws eks update-kubeconfig --name my-cluster --region us-east-1

    # 2. Deploy to K8s
    - name: Deploy to K8s
      run: |
        kubectl set image deployment/my-app \
          my-app=ghcr.io/myorg/my-app:${{ github.sha }}
        kubectl rollout status deployment/my-app

environment: production দিলে GitHub-এ reviewer approve না করলে deploy হবে না।

Branch Strategy: কোথায় কী deploy হবে

feature/* → CI only (test + lint)
develop   → CI + deploy to staging
main      → CI + deploy to production (manual approve)

Secrets Management

- name: Deploy
  env:
    DATABASE_URL: ${{ secrets.DATABASE_URL }}
    API_KEY: ${{ secrets.API_KEY }}

workflow file-এর ভেতরে কোনো configuration related file রাখলে তা leak হওয়ার possibility থাকে। এর জন্য best হচ্ছে GitHub Secrets। এটা securely আপনার environment variable-গুলো maintain করতে help করে।

বটম লাইন

CI/CD মানে শুধু automation না — এটা confidence। Test pass না করলে deploy হবে না। Production-এ কোনো surprises নেই। একবার setup করুন, সারাজীবন সময় বাঁচান।

বি:দ্র: উপরের যে yaml file গুলা লেখা হয়েছে এইগুলো begginer friendly এবং simple ভাবে লেখা হয়েছে। এই গুলাকে আরও better ভাবে লেখা যেতে পারে।

আপনার team কোন CI/CD tool ব্যবহার করছে? কমেন্টে শেয়ার করুন! 👇

Day 27 — Kubernetes — ভয় পাবেন না, ২০% জানলেই ৮০% কাজ হয়

Monirul Islam — Fri, 02 Oct 2026 04:20:00 +0000

এখন আপনার team-এর productivity অনেক বেড়ে গেছে। এখন আপনার application-এর সবকিছুই বলতে গেলে docker এবং docker compose দিয়ে চলে। কিন্তু আপনার application-এর পরিমাণ অনেক বেশি, আলাদা instance রয়েছে, load balancer আছে, database instances আছে। problem হচ্ছে, এখানে আপনি চাইলেই multiple instance run করা যায় তবে এই instance fixed করা থাকে কমানোও যায় না, বাড়ানোও যায় না। শুধুমাত্র আপনাকে manually add করতে হবে। আবার কোনো instance down হয়ে গেলে তাকে restart করার প্রয়োজন হয়। এই সবকিছুই manually করতে হয়। suppose একটা application-এ ৩টা fixed instance আছে। এই ৩টা instance maximum 2k request per second handle করতে পারে। এখন হঠাৎ করে peak time-এ এটা 3k rps-এ চলে গেল। এখন আপনার instance ২টা বাড়াতে হবে। এই আপনি করলেন কিন্তু ১ঘণ্টা পরে load কমে গেল 1k rps-এ। তখন কিন্তু আপনার ২টা instance হলেই enough, বাকি ৩টা instance-এর কিন্তু দরকার নেই। এটা করার জন্য আপনাকে আবার manually code update করে run করা লাগবে।

এখন এটা যদি প্রতিদিন করা লাগে বিষয়টা কেমন হবে just imagine। এটা তো এখন এর থেকেও বড় কথা হচ্ছে, আপনি বুঝবেন কীভাবে load বেড়ে গেছে? load 100% হয়ে গেলে তো সব instance crash করে যাবে। আরও অনেক problem।

এখন এটাই যদি automatically করা যেত তাহলে বিষয়টা কেমন হতো?

আপনার এত tension করা লাগত না। load যখন বেড়ে যাবে তখন automatically instance বেড়ে যাবে (scale up)। load কমে গেলে automatically instance কমতে থাকবে (scale down)। ইচ্ছা মতো container up, down করা যাবে। আরও অনেক problem solve হয়ে যাবে।

বিষয়টা খুবই interesting, তাই না। এই same কাজটাই করে Kubernetes (K8s)।

What is kubernetes?

kubernetes হলো docker compose-এর মতো একটা orchestrator, যার মূল কাজ হচ্ছে container-গুলোকে maintain করা। একে short-এ K8s বলে থাকে। docker compose-এ যেখানে limitation চলে আসে, সেখান থেকেই k8s-এর শুরু। k8s-এর history বলে লাভ নেই। একটু research করলেই পেয়ে যাবেন।

একটু আগে scale up and scale down-এর কথা বললাম, সেই কাজটা k8s easily করতে পারে, automatic-ভাবে। একে autoscaling বলে। automatically scale হবে। তবে এই autoscalling এর জন্য logic এবং পলিসি আগে থেকে code এ লিখে দিতে হয়। K8s-এর নিজস্ব Service object আছে যা internal load balancing করে, এবং cloud provider-এর সাথে মিলে external traffic handle করা একদম সহজ করে দেয়। এছাড়াও auto healing-এর feature-ও k8s-এ আছে।

k8s একটা huge জিনিস। এটা মোটামোটি complex, learning curve অনেক long। আর k8s small to medium application-এর জন্য use করা overkill হয়ে যায়।

K8s কেন দরকার?

কেন দরকার সেটা কিছুটা আন্দাজ করতে পারছেন। সেই বিষয়ে যাওয়ার আগে নিচের question-গুলো নিয়ে একটু ভাবুন:

Container crash করলে কে restart করবে?
Traffic বাড়লে container বা instance কে বাড়াবে?
আবার traffic কমে গেলে instance কে কমাবে?
১০টা server-এ load কীভাবে distribute হবে?

উপরে প্রত্যেক problem-এর solution k8s-এ রয়েছে। এছাড়াও k8s zero down time deployment-এর benefit দেয়। এখানে আপনার application down না করেই নতুন version-এ roll করা যায়। server কোনো ভাবেই down হবে না। gracefully old application-গুলো new version-এর application দিয়ে replace করে দেবে with zero down time।

মূল Concepts — শুধু এগুলো

Pod — K8s সরাসরি container রান করে না, Pod রান করে। এটি ক্লাস্টারের সবচেয়ে ছোট unit, যার ভেতরে এক বা একাধিক container থাকতে পারে (যেমন আপনার main app এবং একটি logging agent)।
Deployment — আপনার অ্যাপের কতগুলো copy (Pod) চলবে এবং কোন image থেকে চলবে তা define করে। কোনো Pod ক্র্যাশ করলে নতুন Pod তৈরি করা বা Zero-downtime আপডেট দেওয়ার দায়িত্ব মূলত এর।
Service — Pods নশ্বর (mortal), এরা dead হয়ে গেলে নতুন IP দিয়ে আবার নতুন করে রান হয়। Service এদের সামনে একটা Fixed IP ও DNS নাম বসিয়ে দেয়, যেন ডাটাবেস বা অন্যান্য অ্যাপ সহজে এদের খুঁজে পায়।
Ingress — বাইরের traffic (ইন্টারনেট) ক্লাস্টারের ভেতরে আসার মেইন দরজা বা Router। কোন ডোমেইন বা URL-এ হিট করলে কোন Service-এ ট্রাফিক যাবে, তা Ingress ঠিক করে দেয়।
ConfigMap / Secret — অ্যাপ্লিকেশনের Environment Variables এবং Configuration কোড থেকে আলাদা রাখার জায়গা। সাধারণ ডাটার জন্য ConfigMap আর পাসওয়ার্ড বা API Key এর মতো সেনসিটিভ ডাটার জন্য Secret ব্যবহৃত হয়।

Deployment & Service: A Real Example

Kubernetes-এ সবকিছু ডিক্লেয়ার করা হয় YAML ম্যানিফেস্টের মাধ্যমে:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-backend-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate # Zero-downtime rolling update
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: my-backend
  template:
    metadata:
      labels:
        app: my-backend
    spec:
      containers:
        - name: app
          image: my-backend:v1.0.0
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
---
# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-backend-service
spec:
  type: ClusterIP
  selector:
    app: my-backend
  ports:
    - port: 80
      targetPort: 3000

HPA (Horizontal Pod Autoscaler): অটো-স্কেলিং 📈

ম্যানুয়ালি ৩টি বা ৫টি Pod নির্দিষ্ট না রেখে, ট্রাফিকের ওপর ভিত্তি করে স্বয়ংক্রিয়ভাবে Pod সংখ্যা বাড়ানো বা কমানোর কাজ করে HPA. For example:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-backend-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-backend-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70 # CPU ব্যবহার ৭০% পার হলে নতুন Pod তৈরি হবে

K8s in small application

শুনতে এত জোস লাগলেও, একটা ছোট বা মিডিয়াম সাইজের প্রোজেক্টে, যেখানে ইউজার বেস কম এবং ট্রাফিক প্রেডিক্টেবল, সেখানে K8s সেটআপ করা মানে নিজের পায়ে নিজে কুড়াল মারা। কেন? চলুন একটু ভেঙে বলি:

Overkill Architecture & Complexity: Kubernetes এর নিজস্ব একটা বিশাল লার্নিং কার্ভ (Learning curve) আছে। Pods, Deployments, Services, Ingress, ConfigMaps—এসব মেইনটেইন করতেই আপনার জান বের হয়ে যাবে। যে সময়টা আপনি কোড ইমপ্রুভমেন্ট বা বিজনেজ লজিকে দিতে পারতেন, সেটা চলে যাবে ক্লাস্টার কনফিগার করতেই।
Infrastructure Cost (পকেটের টান): K8s চালাতে গেলে মিনিমাম একটা Control Plane (Master Node) আর কয়েকটা Worker Node লাগে। ছোট একটা অ্যাপের যে রিসোর্স লাগবে, তার চেয়ে বেশি রিসোর্স খরচ হয়ে যাবে শুধু Kubernetes ক্লাস্টারটাকে টিকিয়ে রাখতে। ক্লাউড বিল দেখে তখন কপালে হাত পড়বে!
Operational Overhead: এটাকে ম্যানেজ করার জন্য ডেডিকেটেড DevOps ইঞ্জিনিয়ার বা এক্সপার্টাইজ লাগে। ছোট টিমে ডেভলপাররাই যখন DevOps-এর কাজ করে, তখন এই ওভারহেড প্রোডাক্টিভিটি কমিয়ে দেয়।

তাহলে উপায় কি?

আপনার অ্যাপ্লিকেশন যদি ছোট হয়, তাহলে অযথা Kubernetes ব্যবহার করার দরকার নেই। সিম্পল এবং ইফেক্টিভ কিছু অল্টারনেটিভ অলরেডি মার্কেটে আছে:

Docker Compose: সিঙ্গেল ভার্চুয়াল মেশিনে (VM) মাল্টিপল কন্টেইনার চালানোর জন্য বেস্ট এবং একদম সিম্পল।
Docker Swarm: Docker এর নিজের Orchestration tool. K8s এর থেকে অনেক simple আর easy to learn।
Managed Platforms: Render, Railway, বা DigitalOcean App Platform-এর মতো সার্ভিসগুলো ইউজ করতে পারেন। কোনো ইনফ্রাস্ট্রাকচারের চিন্তা ছাড়াই জাস্ট কোড পুশ করলেই লাইভ!
VPS (Virtual Private Server): একটা সিম্পল Hetzner বা DigitalOcean Droplet-এ Docker দিয়ে সেটআপ করে নিলেই বছরের পর বছর শান্তিতে চালানো যায়।

বটম লাইন

কুবারনেটিস টেকনোলজি হিসেবে অসাধারণ এবং বড় স্কেলের মাইক্রোসার্ভিস আর্কিটেকচারের জন্য এটার কোনো বিকল্প নেই। কিন্তু হাইপ বা ট্রেন্ডের পেছনে ছুটে ছোট অ্যাপে K8s ঢুকিয়ে কমপ্লেক্সিটি বাড়ানোর কোনো মানে হয় না। তবে k8s ব্যবহার করতে হয় তাহলে একেবারে বেসিক দিয়ে শুরু করুন। Deployment, Service, HPA, Ingress — এই চারটা দিয়েই ৮০% production workload handle করা যায়, এই গুলা শিখে শুরু করুন পরে প্রয়োজন হলে শিখে নিবেন।

আপনি কি K8s ব্যবহার করছেন? সবচেয়ে কঠিন কোন concept মনে হয়েছে? কমেন্টে শেয়ার করুন! 👇

Day 26 — Docker — 'আমার machine-এ চলে' এই অজুহাত চিরতরে বন্ধ করুন

Monirul Islam — Thu, 01 Oct 2026 04:20:00 +0000

আপনার company অনেক বড় হয়ে গেছে। মোটামুটি প্রায় ২০০ জন engineer। হঠাৎ করেই একটা pandemic চলে এল। govt থেকে lockdown দিয়ে দিলো। এখন office-এ যেয়ে কাজ করার সুযোগ নেই। এখন সবাইকেই remotely বাড়ি থেকে কাজ করতে হবে। এখানে আপনার একটা লাভ হলো যে সব engineer-এরই একটা করে computer/laptop আছে। আর ১০-১২ জনের ছিল না, আপনি তাদের জন্য সেটার ব্যবস্থা করে দিলেন।

এভাবেই office শুরু হলো। কাজ চলতেছে। ১ মাস এই ভাবেই চললো। তারপর আপনি একটা জিনিস realize করলেন কাজের productivity কমে গেছে। আগে যেখানে ১ মাসে ১৫-২০ টা feature আরামসে complete হয়ে যেত, এখন ৪-৫ feature complete করতেই অবস্থা খারাপ হয়ে গেছে। বিষয়টা খুবই concerning। সবগুলো না হোক অন্তত ১২-১৫ টা feature তো complete করতে হবে।

এই বিষয়টা address করার জন্য আপনি সকল team leader-দের নিয়ে meet করলেন। একটা ২ ঘন্টার long meeting হলো। ভালো খারাপ সব নিয়েই কথা হলো। তবে ভালোর থেকে খারাপ বিষয়গুলোই বেশি ছিল। meeting-এর summary হচ্ছে এই রকম:

"আমার machine-এ কাজ করে": এই simple line নাকি সবার মাঝে common হয়ে গেছে। মূল সমস্যা হলো যখন কেউ কোনো feature develop করে তখন অন্য আরেকজনের computer-এ properly run হয় না, configuration-এর problem। এই problem solve করতেই অবস্থা খারাপ। এই problem solve করার পর, যে develop করেছে তার machine থেকে আবার try করলে আবার same problem। এই ভাবেই দিনের অর্ধেক time চলে যাচ্ছে।
এছাড়াও deploy করার সময়ও problem হচ্ছে। সেখানেও critical problem দেখা দিচ্ছে। deploy-এর সময় problem হচ্ছে। properly deploy হচ্ছে না।

এখানে মূল বিষয় হচ্ছে, engineer যেখানে feature development-এ focus দিবে সেখানে তারা configuration related problem solve করতেই সবচেয়ে বেশি সময় নষ্ট করছে। বিষয়টা আসলেই গুরুতর।

আপনার একটা জিনিস মাথায় আসল, আগে office থাকতে তো এই রকম কোনো problem হয়নি তাহলে এখন এত problem হচ্ছে remotely কাজ করার জন্য? না, remotely কাজ করলে তো আর তাদের skill কমে যাবে না। বিষয়টা হচ্ছে আগে যখন সবাই office-এ কাজ করত তখন সবাই same configuration-এর machine use করত। সবার machine same ছিল। আর সবাই একসাথে কাজ করার কারণে কোনো সমস্যা হলে instant solve হয়ে যেত।

এটা কীভাবে solve করা যায়। সবাইকে তো আর same machine দিয়ে দেয়া যাবে না। আর সবার কাছে তো same type computer নেই। কেউ linux, কেউ windows আবার macOS use করে। এখন চাইলেই এটা করা যাবে না। এর থেকে better solution লাগবে।

solution কি আছে??

হ্যাঁ, অবশ্যই আছে। His name is Docker।

Docker

docker হলো একটা tool বা software, এটা use করে আপনার problem easily solve করা যায়। docker containerization নামে একটা feature আছে যেটা আপনার application-কে একটা isolated environment-এ run করবে। এই environment-টায় একটা dedicated operating system থাকে। এই operating system-এ outsider-এর কোনো effect থাকে না সেটা linux হোক, বা windows হোক, বা macOS হোক।

এখানে অনেকটা ship-এর কথা চিন্তা করতে পারেন। জাহাজে কিন্তু অনেক container থাকে। সেখানে কিন্তু একটা container অন্য একটা container-কে affect করে না। যে যার মতো। ভেতরে যা আছে সবকিছুই isolated। আর ship কিন্তু অনেকগুলো container একসাথে carry করতে পারে।

এখানে docker container হলো ship-এর container আর ship-টা হচ্ছে host machine। তবে আপনার laptop, বা computer বা macOS যেটাই হোক না কেন, সেটাই basically host machine।

docker-এর সবচেয়ে বড় সুবিধা হচ্ছে, আপনার machine-এ যা চলছে যেভাবে চলছে, ঠিক সেভাবে আপনার colleague-এর machine-এ, আবার production server-এ same ভাবেই run করবে। আর কেউ কিছু change করলেও same configuration-এর কারণে same result-ই পাবে। "আমার machine-এ কাজ করে" এটা থেকে মুক্তি পেয়ে যাবেন।

আপনি যদি docker-এ নতুন হন তাহলে একটু confusion হতে পারে। আমারও হয়েছিল। আস্তে আস্তে সবকিছু clear হয়ে যাবে।

Why not Virtual Machine?

আপনি যদি কখনো virtual machine use করে থাকেন তাহলে আপনার মনে এই question-টা আসতেই পারে। VM machine করলেই তো হয়। এত complicated জিনিসের বা কী দরকার। হ্যাঁ, অবশ্যই দরকার।

বিষয়টাতে যাওয়ার আগে docker কীভাবে কাজ করে সেটা জানার প্রয়োজন। Docker কোনো আলাদা Operating System run করে না। এটি Host machine-এর kernel share করে এবং শুধুমাত্র অ্যাপ্লিকেশনের জন্য প্রয়োজনীয় library ও dependency গুলো রান করে। আর host machine এর resource by default ভাবেই use হবে। এই architecture-এর কারণেই একটা docker container-এর size খুবই lightweight হয়। একটা typical nodejs এর docker image এর size 50-100mb এর মধ্যে হয়। তবে container রান করলে সেখানে মোটামুটি ৫০০-৭০০mb ram use হতে পারে।

vm-এ সবকিছুই তার own operating system + own kernel + more isolated environment। এই সমস্ত কারণে vm-এর size খুবই বেশি হয়। অনেক ক্ষেত্রে 5-10gb হয়ে যায়। আর startup time অনেক বেশি।

এখন চিন্তা করেন, সবাইকে যদি এই 5-10gb-এর vm-কে transfer করা যায়, setup করা ঝামেলা। আর suppose কেউ কোনো feature add করলো তখন তো পুরো vm-টাই transfer করা লাগবে। কী একটা pain!

এখানে docker help করে, আপনি চাইলে আপনার code দিয়ে আপনার নিজের machine-এই docker container build করতে পারেন। আপনার 700-800mb container transfer করা লাগবে না।

এই সমস্ত কারণেই মূলত docker-টা use করাই সবচেয়ে ভালো। এছাড়াও আরও অনেক সুবিধা আছে। যেমন ধরুন deployment একদম পানির মতো easy করে দিবে। CI/CD নিয়ে আলোচনা হবে তখন deployment নিয়ে কথা হবে।

Dockerfile: Recipe লিখুন

আপনারা যারা জীবনে একবার হলেও, computer-এ windows বা linux setup করেছেন তখন দেখবেন, আপনাকে অনেক কিছু set করে দিতে হয়। windows-এর কোন version use করবেন বা linux-এর মধ্যে কোন linux, ubuntu নাকি mint নাকি অন্য কিছু। এবং এই সবকিছু ঠিক করার পরে কিন্তু মোটামুটি অনেক time লাগে setup complete হতে।

কখনো ভেবে দেখেছেন এই সময়টাতে কী হয়? এই সময়েই মূলত OS-এর জন্য file-গুলো আসে সেগুলো ready করা হয় এবং আপনার system-এর drive-এ push করা হয়। নানারকম system preference আছে সেগুলো set করা হয়। যখন সবকিছু ঠিক হয়ে যায় তারপরে যেয়ে আপনি computer use করতে পারেন।

একটু আগে আমি বললাম যে docker operating system run করে application run করে। সে তো আর জানে না যে আমার কোন operating system use করতে হবে আর use করার পর application-টাকে কীভাবে setup করে run করতে হবে। তাকে তো বলে দিতে হবে। না হলে তো কিছুই বুঝবে না। For example, আপনার nodejs application run করার জন্য আপনার system-এ nodejs install থাকতে হবে। তা নাহলে তো সেই application run হবে না।

এটার জন্য একটা recipe বা configuration লিখতে হয়, যাকে বলে dockerfile। নিচে একটা dockerfile-এর example দেখতে পারবেন।
ভয় পাওয়ার দরকার নেই আস্তে আস্তে শিখে যাবেন। খুব কঠিন কিছু না।

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .

RUN npm run build

EXPOSE 3000

CMD ["node", "dist/main.js"]

এখানে একটা nodejs application run করার জন্য লেখা হয়েছে। Node-20 এর alpine version-টা use করা হয়েছে এবং প্রয়োজনীয় সকল dependencies-গুলো setup করা হয়েছে।

Layer Caching: Build Fast করুন

উপরের dockerfile দেখে একটা question arise হতে পারে। যে এত line লেখার কী আছে। 3-4 line-এই তো শেষ করা যেতে পারে।
এখানেই বিষয়টা সে docker-এর build process। dockerfile build হওয়ার time-এ line by line data cached করে রাখে। যেই line থেকে আবার নতুন করে build হবে। For example,
আপনি যদি package.json file কোনো change না করে থাকেন তাহলে সেটা COPY . . থেকে নতুন build শুরু হবে। তার আগে যেগুলো build হয়েছে সেগুলো cached data থেকে use করবে। আর যদি package.json file-এ change করে থাকেন তাহলে ঐ line থেকে আবার নতুন করে build শুরু হবে।
এই জন্যই মূলত dockerfile multiple line-এ লেখা হয়। এতে container-এর size কমে।

নিচের example দেখলে আরও ভালো বুঝতে পারবেন।

# ✅ dependencies আগে — কম পাল্টায়
COPY package*.json ./
RUN npm ci

# ✅ source code পরে — বেশি পাল্টায়
COPY . .
RUN npm run build

Docker Image

আপনি যখন কোনো OS setup করেন তখন আপনার কাছে একটা .img file থাকে। এই file-টা আপনার system computer-এ setup করার পরেই কিন্তু windows run হয়।
এখানে বোঝার বিষয় হচ্ছে, এখানে এই .img file-টা কিন্তু একা একা চলতে পারবে না। বা আপনার ঐ .img-টা বাদেও শুধু hardware দিয়ে কাজ হবে না। মূলত operating system-এর সব files (kernel, system files, file systems etc.) এই .img file-এর মধ্যে থাকে, অনেকটা zip file-এর মতো করে একসাথে করে রাখা হয়।

docker-এর জন্য, only application run করার জন্য needed files-গুলো একসাথে করে একটা file create করা হয়। এইগুলো কে docker image বলে। এই image-গুলোকে একটা container-এর মধ্যে run হয়। আর container কীভাবে কাজ করে উপরে মোটামুটি বলেছি বুঝে গেছেন।

Dockerfile থেকেই এই image-গুলো create করতে হয়। তারপর docker-এর মাধ্যমে এগুলো run করতে হয়।

Multi-Stage Build: প্রোডাকশন ইমেজ সাইজ ৮০% কমান ⚡

একটি সাধারণ TypeScript বা modern Node.js app-কে বিল্ড করার জন্য TypeScript কম্পাইলার tsc, linter এবং অনেক devDependencies দরকার হয়। কিন্তু প্রোডাকশনে এই app এর build run করলেই হয়ে যায়।

এগুলোকে image-এ রেখে দিলে dokcer image এর size 700-800 mb হয়ে যায়। ক্ষেত্র বিশেষ আরও বেশিও হতে পারে। এই সমস্যার সেরা সমাধান হলো Multi-Stage Build। এখানে শুধু একটা stage থেকে আরেকটা stage-এ প্রয়োজনীয় ফাইলগুলা transfer হবে।

# --- Stage 1: Build Stage ---
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build


# --- Stage 2: Production Runtime Stage ---
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production

# শুধু প্রোডাকশন ডিপেন্ডেন্সি ইনস্টল
COPY package*.json ./
RUN npm ci --omit=dev

# স্টেজ ১ থেকে শুধু বিল্ড হওয়া dist ফোল্ডার কপি
COPY --from=builder /app/dist ./dist

# Security: Root হিসেবে রান না করে non-root user ব্যবহার
USER node

EXPOSE 3000

CMD ["node", "dist/main.js"]

এর সবচেয়ে বড় সুবিধা হচ্ছে docker image-এর size ৭০-৮০% কমে যায়। এছাড়াও production-এর জন্য প্রয়োজনীয় ফাইলগুলোই image-এর ভেতরে থাকে।

Docker Compose: Multi-Service Local Dev

একটা জিনিস, আপনার application-এ কিন্তু অনেক configuration করতে হয়। এগুলো application-এর outside থেকে provide করতে হবে। না হলে একটা security risk তৈরি হতে পারে। এখন আপনি চাইলেই আপনার docker container প্রতিবার configurations type করে run করতে পারেন। কিন্তু যদি নতুন কোনো কিছু add করা লাগে বা delete করা লাগে তখন কী করবেন? তখন কিন্তু বিষয়টা pain হয়ে যাবে। এছাড়া আমি একটু বললাম যে, docker system resource use করে, সেখানেও তো limit করা লাগবে। এগুলো তো arbitrary ভাবে করা যাবে না। একটা proper way লাগবে।

এই problem-টাকে address করার জন্য, docker introduce করে, একটা orchestrator, যেটা হলো docker compose। একটা band-এ orchestrator কী করেন সেটা তো জানেন। তিনি instruction দেন কখন কোন instrument-টা বাজাতে হবে, কতক্ষণ বাজবে এবং কখন বন্ধ হবে etc. মানে তিনিই সবকিছু control করে থাকেন। docker compose-ও same কাজটাই করে থাকে।

docker compose মূলত image file run করে। আর মজার ব্যাপার হচ্ছে এই compose file দিয়েই docker image build করা যায়। আর সেই image-গুলো compose file দিয়েই run করা যায়। এছাড়াও existing image-ও run করা যায়।

services:
  app: # application container
    build: . # builidng with existing Dockerfile file
    ports:
      - "3000:3000" # mapping port 3000 of host to container
    environment: # environment variables
      DATABASE_URL: postgresql://postgres:password@db:5432/mydb
    depends_on: # dependencies
      - db
      - redis

  db: # container for database
    image: postgres:16-alpine # existing external postgres image
    environment: # environment variables
      POSTGRES_PASSWORD: password
      POSTGRES_DB: mydb
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine # external redis image

volumes:
  pgdata: # volume data

এখানে PostgreSQL database and redis-এর জন্য external image use করা হয়েছে।

docker compose up -d

এই একটা command-এ সবগুলো container একসাথে run হবে। কোনো কিছু করা লাগবে না। এক বারে সবকিছু ready।

.dockerignore: অপ্রয়োজনীয় বাদ দিন

এই পর্যন্ত যখন এসেছেন তাহলে git সম্পর্কে অবশ্যই জানেন। use-ও করতে পারেন। একটা জিনিস খেয়াল করবেন, আপনি কিন্তু github-এ node_modules, configurations, .env, build files এগুলো push করেন না। কেন করেন না? কারণ এগুলো আপনি চাইলেই externally install করতে পারবেন। docker-এর ক্ষেত্রেও একই rules প্রযোজ্য।

git-এর জন্য .gitignore use হয়, docker-এর জন্য .dockerignore file use হয়।

অনেকে মনে করেন এটি শুধু ইমেজ সাইজ ছোট রাখার জন্য ব্যবহার করা হয়। কিন্তু এর চেয়েও বড় একটি কারণ রয়েছে।
আপনার লোকাল ল্যাপটপ যদি macOS বা Windows হয়, আপনার লোকাল node_modules-এ থাকা লাইব্রেরিগুলো (যেমন bcrypt, sharp, prisma) আপনার নিজস্ব OS-এর আর্কিটেকচারে কম্পাইল করা থাকে। .dockerignore-এ node_modules না রাখলে COPY . . কমান্ডটি সেই ফাইলগুলো ডকারের Linux কন্টেইনারে কপি করে দেবে—যার ফলে কন্টেইনারে invalid ELF header বা আর্কিটেকচার মিসম্যাচ এরর দিয়ে অ্যাপ ক্র্যাশ করবে!

node_modules
.git
.env
*.log
dist

উপরের যে list-এ যেগুলো আছে এগুলোর খুব বেশি দরকার নেই। এখানে .env file-টাও skip করা হয়েছে, security risk এর জন্য।

বটম লাইন

Docker simply আপনার development workflow smooth and easy করে দিবে। অনেক problem-এর solution করবে যেগুলো হয়তো আপনি চিন্তাও করতে পারবেন না। একটা distributed system, distributed remote team-এর জন্য docker must।

আপনার project-এ Docker ব্যবহার করছেন? কোন সমস্যায় পড়েছেন? কমেন্টে শেয়ার করুন! 👇

Day 25 — Circuit Breaker Pattern — একটা service-এর ব্যর্থতায় পুরো system যেন না পড়ে

Monirul Islam — Wed, 30 Sep 2026 04:20:00 +0000

আপনার application, আপনার business সবকিছুই আরামসে চলছে। এখন আপনি লাখপতি থেকে কোটিপতি হয়ে গেছেন। এতদিনে আপনি একটা জিনিস বুঝে গেছেন। server not found error বা server timeout error থেকে server is under maintenance error টা তুলনামূলক ভাবে ভালো।

এখন আপনার application-এ তেমন critical error নেই। যা ছিল সব solve হয়ে গেছে।

কিন্তু মাঝে মাঝে কয়েকটা incident হচ্ছে যেখানে আপনার server crash করছে নানা কারণে। এই জিনিসটা এখন solve করা দরকার। এখন এখানে auto recover করার system-টা on করতে হবে। কিন্তু problem হচ্ছে, system জানবে কীভাবে যে system recover করেছে। আর এই recover করার সময়েই তো user-দেরকে stop করতে হবে। তারা যেন server-এ access করতে না পারে। access করলে তো আবার problem হয়ে যেতে পারে। recover fail করতে পারে। তখন আবার problem।

এর একটা ব্যবস্থা করা দরকার। বিষয়টা এমন না যে করতেই হবে। কারণ এই case-গুলো মাঝে মাঝে rarely হয়ে থাকে। তবে এতে user-এর experience নষ্ট হবে।

এই problem-এর solution already বিদ্যমান, Circuit Breaker।

Circuit Breaker কীভাবে কাজ করে?

আমরা সবাই মোটামুটি electric circuit breaker সম্পর্কে জানি। জানার কথা। অনেক জায়গায় এটাকে main switch-ও বলে। এই electric circuit breaker-এর কাজ হচ্ছে, যখন প্রয়োজনের তুলনায় load বেশি হবে তখন connection-টাই বন্ধ করে দেবে। এতে করে কোনো unwanted situation create-ই হবে না। for example, বৃষ্টির সময় বজ্রপাত হলে এইসব circuit breaker-গুলো connection বন্ধ করে দেয়। এতে electric device-গুলো protect হয়ে যায়।

electrical circuit breaker-এর মতো করেই software circuit breaker কাজ করে। যখন system-এ কোনো problem হয় তখন সেটা protect করে। application-কে recover হওয়ার সময় দেয়।

এখানে তিনটা state:

Closed (Normal) — এই state-এর মানে হচ্ছে circuit close আছে, request normal way-তে যাবে। কোনো request fail হলে request-গুলো count হবে। এই failure count একটা threshold cross করলে circuit open state-এ চলে যাবে।
Open (Tripped) — এই state-এর মানে হচ্ছে circuit open হয়ে গেছে। আর কোনো request-ই process হবে না। direct fallback return হবে। এই state-এ আরেকটা কাজ করা হয়ে থাকে, এখানে একটা সময় পরে যেয়ে circuit half-open state-এ চলে আসবে।
Half-Open (Testing) — এই state সবচেয়ে বেশি important। এই state-এ মূলত check হয় যে system recover করেছে কি না। যদি recover হয়ে থাকে তাহলে circuit-এ আবার closed state-এ চলে যাবে। আর যদি fail হয় তাহলে open state-এ চলে যাবে এবং আরেকটু বেশি সময় wait করবে। এই waiting time-টা generally exponential হয়ে থাকে।

Basic Implementation

এখানে একটা simple circuit breaker implement করা হয়েছে। এটা simple একটা। আপনার requirement অনুযায়ী আপনি আপনার মতো করে বানিয়ে নিতে পারেন। কীভাবে করবেন সেটা আপনার requirement এবং decision-এর উপর depend করছে।

// nestjs-opossum বা custom implementation
class CircuitBreaker {
  private state: "CLOSED" | "OPEN" | "HALF_OPEN" = "CLOSED";
  private failureCount = 0;
  private failureThreshold = 5;
  private recoveryTimeout = 30000; // 30s
  private lastFailureTime = 0;
  private isTestingRecovery = false; // Single-trial guard for HALF_OPEN

  async execute<T>(fn: () => Promise<T>, fallback?: () => T): Promise<T> {
    const now = Date.now();

    // 1. OPEN to HALF_OPEN Transition Check
    if (this.state === "OPEN") {
      if (now - this.lastFailureTime > this.recoveryTimeout) {
        this.state = "HALF_OPEN";
      } else {
        if (fallback) return fallback();
        throw new Error("Circuit is OPEN");
      }
    }

    // 2. HALF_OPEN State: Allow only ONE trial request
    if (this.state === "HALF_OPEN") {
      if (this.isTestingRecovery) {
        // Another probe request is already in-flight; fallback for others
        if (fallback) return fallback();
        throw new Error("Circuit is recovering (HALF_OPEN)");
      }
      this.isTestingRecovery = true;
    }

    try {
      const result = await fn();
      this.onSuccess();
      return result;
    } catch (error) {
      this.onFailure();
      if (fallback) return fallback();
      throw error;
    } finally {
      if (this.state !== "HALF_OPEN") {
        this.isTestingRecovery = false;
      }
    }
  }

  private onSuccess() {
    this.failureCount = 0; // Reset counter on success!
    this.state = "CLOSED";
    this.isTestingRecovery = false;
  }

  private onFailure() {
    this.failureCount++;
    this.lastFailureTime = Date.now();
    this.isTestingRecovery = false;

    if (
      this.state === "HALF_OPEN" ||
      this.failureCount >= this.failureThreshold
    ) {
      this.state = "OPEN";
    }
  }
}

এখানে আপনাকে প্যারা নেয়ার দরকার নেই। বানাতে সময় লেগে যেতে পারে। bug থাকার possibility তো থাকেই। এর জন্য existing অনেক library আছে যেখানে অনেক feature already exist করে। for example,

opossum in nodejs
resilience4j in java
sony/gobreaker in golang
failsafe-rs in rust
pybreaker in python

Fallback: Graceful Degradation

Circuit open হলে কী return করব?

এই question-টা circuit breaker-এর implementation-ই change করে দিবে। এখানে আপনাকেই decision নিতে হবে যে আসলে আপনি কী return করবেন। এখানে fallback strategy-তে কিছু option আছে:

Return static/cached/default/partial data
Return exception with error message
Inform user about the issue
Show skeleton/loading state

এখন আপনি কোনটা use করবেন সেটা আপনার application-এর উপর depend করছে। for example,

একটা blog site-এ আপনি চাইলেই cached data fallback হিসেবে দিতে পারেন।
ecommerce-এর ক্ষেত্রে cached data use করা যেতে পারে। কারণ product-এর details তো আর খুব একটা change হয় না। তবে এখানে আপনার requirement-এর উপর depend করবে যে আপনি কী করবেন।
banking-এর ক্ষেত্রে আপনি এখন কিন্তু cached data fallback হিসেবে দিতে পারেন না। কারণ এখানে current data-টা খুবই important। এখানে হয় error return করে user-কে inform করাটা better হবে।

এই রকম আরও situation-এ পড়তে পারেন। এইসব জিনিসটা আপনার requirement এবং application-এর উপর depend করবে। এখানে কোনো boundary নেই। আপনার যেটা দরকার সেটাই করবেন। NO worries।

এখানে just simple একটা fallback দিয়ে code generate করা হয়েছে।

const productData = await circuitBreaker.execute(
  () => productService.getDetails(productId),
  () => ({ name: "Product", price: 0, cached: true }), // fallback
);

আপনি যখন partial বা cached data fallback হিসেবে use করছেন তখন কিন্তু user কিছু একটা দেখতে পাচ্ছে। application-টা full blank হয়ে যাবে না। এই জিনিসটাকে বলে Graceful Degradation।

Retry Pattern: বুদ্ধিমানের মতো retry

উপরে একটা জিনিসের হালকা কথা বলেছিলাম যে, একটা সময় পর circuit breaker check করবে যে system ঠিক আছে কি না। fail করলে একটা সময় পরে আবার retry করতে হবে। এই retry করার time-টা এমনভাবে use করতে হবে যেন আপনার system recover হওয়ার আগেই fail করে না যায়। এই retry-এর time-টা most of the time exponential time use করা হয়ে থাকে। এতে করে server enough time পাবে recover করার জন্য। নিচের example-টা থেকে বিষয়টা বুঝতে পারবেন।

Exponential Backoff — প্রতিবার wait বাড়াও:
1st retry: 1 second পর
2nd retry: 2 seconds পর
3rd retry: 4 seconds পর
4th retry: 8 seconds পর

অনেক ক্ষেত্রে exponential backoff use করার পরও server recover হয় না। তখন একটা maximum time set করে দিতে হয়, যাতে করে server-এর ওপর বেশি pressure না পড়ে। আবার অনেক সময় অনেকগুলো client একসাথে request send করে তখন আরেকটা issue হতে পারে। সেক্ষেত্রে jitter technique use করা যেতে পারে।

বটম লাইন

Microservice আর distributed system-এ failure inevitable। Circuit Breaker, Retry — এই pattern গুলো failure-কে gracefully handle করে। একটা dependent service-এর failure পুরো system ফেলে দিতে পারবে না।

আপনার system-এ কোন resilience pattern ব্যবহার করছেন? কমেন্টে শেয়ার করুন! 👇

Day 24 — CQRS ও Event Sourcing

Monirul Islam — Tue, 29 Sep 2026 04:20:00 +0000

আপনার application দিব্যি চলেছে, traffic বাড়ছে। এখন Perfectly সবকিছু চলছে। Business-ও grow করছে, profit-ও দিন দিন বাড়ছে। ভালোই। এভাবেই ২-৩ মাস ভালোই চললো। কিন্তু সমস্যা হলো database load নিয়ে। Database slow হয়ে গেলো। User-রা তাদের important information-গুলো পাচ্ছে না।

আগের মতোই, same way-তে application debugging শুরু করলেন। এখন কিন্তু আপনি একা না। তাই কয়েক ঘণ্টার ভেতরেই সব issue-গুলো পেয়ে গেলেন। সমস্যাগুলো ঠিক এরকম:

Feed application-এ post read-এর থেকে write বেশি হচ্ছে। Caching দিয়েও কাজ হচ্ছে না। কারণ frequently write হচ্ছে। আর cache regularly invalidate হচ্ছে। Read বেশি হওয়ার কারণে database-এর limit শেষ হয়ে যাচ্ছে। অনেক read হওয়ার কারণে অনেক user write করতে পারছে না।
Cache service এখানে অনেকটা useless হয়ে যাচ্ছে কারণ frequently cache update করতে হচ্ছে।

এখন problem তো পেয়ে গেছেন। আর আপনি ভালো করেই জানেন problem properly খুঁজে বের করা মানেই problem অর্ধেক solve হয়ে গেছে। এখন আপনার মাথায় একটা idea আসলো, read আর write-এর জন্য আলাদা database use করলে কেমন হয়। কিন্তু এতোদিনে বুঝে গেছেন, একটা simple জিনিসকে distribute করলে সেখানে limitless problem হাজির হয়। Distribute system is nightmare.

আপনার এই idea-টা আপনি আপনার team member-দের কাছে share করলেন, brain storming শুরু হলো। অনেকগুলো question এবং possible complexity-গুলো হাজির হলো। যেমন:

২টা database maintain কিভাবে করবো, manpower লাগবে, budget লাগবে।
Write এবং read database-এর জন্য আলাদা আলাদা model, access modifier, response change হওয়ার possibility থাকতে পারে।
Write-এর জন্য যে schema use করবো, তার সাথে read-এর জন্য আলাদা schema use করলে communication কিভাবে করবো।
Data replicate কিভাবে করবো, read এবং write database-এর ভেতরে replication-টা কিভাবে হবে।
কোনো একটা database fail হলে কি হবে। Backup কিভাবে নিবো। Failover-টা কিভাবে হবে।

এখন এই প্রত্যেকটা problem solve করার জন্য, আপনি যদি নিজে solution বের করতে চান, তাহলে সময় লাগবে, manpower লাগবে।
কিন্তু কথা হচ্ছে, আপনার এতো চিন্তা করা লাগবে না, এই problem-গুলো address করার জন্য একটা architecture already বিদ্যমান আছে।
CQRS (Command Query Responsibility Segregation) is the solution.

CQRS: Command Query Responsibility Segregation

CQRS-এর full form হচ্ছে Command Query Responsibility Segregation। নামটা শুনে কেমন একটা মনে হচ্ছে যে, কোনো responsibility আলাদা করা লাগবে। এখানে command-এর মানে write operations এবং query-এর মানে হচ্ছে read operation। CQRS pattern-এ read আর write operation-এর যে responsibility আছে সেটা segregate বা আলাদা করা।

নিচের code-গুলো দেখেন। দেখলে idea-টা পাবেন।

// সব কাজ একই model
const user = await userService.findById(id);
await userService.update(id, data);

CQRS-এ:

// Write side — Command
await commandBus.execute(new UpdateUserCommand(id, data));

// Read side — Query
const userView = await queryBus.execute(new GetUserQuery(id));

কেন আলাদা করব?

এখন আপনার arise হওয়া question-গুলোর solution CQRS-এ already বিদ্যমান।

আপনি কিন্তু এখন আর একা নন। আপনার team আছে। Manpower আছে। এটাকে easily handle করা যাবে। আর profit-ও তো হচ্ছে। এর জন্য নতুন ১-২ জন hire করলে খুব বেশি problem হবে না। বা আপনার existing team member-দের এখানে assign করলেই হয়ে যাবে।
এটা CQRS model-এর issue না। মূলত এটা আপনার development এবং UI-কে optimize করতে help করবে। কারণ write-এর operation থাকবে business এবং database perspective-এ আর read operation related কাজগুলো হবে UI optimization করার জন্য। সেখানে response model আলাদা রাখলে কোনো problem হবে না।
এই Architecture কাজ করবে asynchronous model-এ। প্রথমে সবকিছুই write database-এ write হবে, then, eventually সেই data read DB-তে asynchronously replicate হবে।
২টা database-এর মধ্যে data synchronization-এর জন্য event use করা হয়। এটাকে আপনি event driven architecture-ও বলতে পারেন। আর event driven architecture সম্পর্কে তো অনেক আগে থেকেই জানেন।
Write DB-টাই মূলত database-এর source of truth। Read DB, write থেকেই replication হয়। কোনো কারণে read DB fail করলে, write DB থেকে replicate করে নিলেই হয়ে যাবে।

এগুলো সবই CQRS-এর part।

Read write operation আলাদা কেন করবেন সেটা তো already বুঝে গেছেন।

Event Sourcing: History-র পুরো বই

Event সম্পর্কে মোটামুটি idea হয়ে যাওয়ার কথা। এখন বলবেন event আর event sourcing তো একই জিনিস। না। Event sourcing বোঝার আগে একটা গল্প বলি।

মনে করুন, আপনার application-এর জন্য একটা bank account খুললেন। খোলার পরে ৫০,০০০ টাকা deposit করলেন। এরপর ২০,০০০ টাকা withdraw করলেন। ৫,০০০ টাকা transfer করলেন। তারপরে আবার ১০,০০০ টাকা deposit করলেন।

এখন আপনার account-এ কত টাকা আছে? কিন্তু এখানে সমস্যা হচ্ছে আপনার কাছে এমন কোনো access নেই যার মাধ্যমে আপনি জানতে পারবেন যে আপনার current balance কত। এখানে আপনি একটু বুদ্ধি খাটিয়ে বের করে ফেলতে পারেন, আপনি যা করেছেন সেগুলো replay বা calculate করে। তাহলে final balance কত হবে: ৫০,০০০ - ২০,০০০ - ৫,০০০ + ১০,০০০ = ৩৫,০০০।

Event sourcing জিনিসটা অনেকটা এরকম। কোনো single value store না করে event-গুলো properly store করে, সেগুলো process করে current state কে বের করা হয়। এই যে কোনো single state use না করে event-গুলো store করে সেগুলো process করাই হচ্ছে event sourcing।

একটা example দিলে বুঝতে পারবেন। সাধারণত আমরা current state-কেই database-এ store করি এবং সেটাই প্রয়োজনে mutate করে use করি। For example:

user: { balance: 5000 }

এখানে বোঝাচ্ছে user-এর balance ৫০০০। এখন deposit বা withdraw করলে current state update হয়ে যাবে। Transfer করলেও এই same state mutate হবে।

কিন্তু event sourcing-এর ক্ষেত্রে কোনো fixed state থাকে না। Multiple event-গুলো store রাখা হয়। For example:

AccountOpened { balance: 10000 }
MoneyWithdrawn { amount: 2000 }
MoneyDeposited { amount: 500 }
MoneyWithdrawn { amount: 3500 }

এখানে আগের মতো কোনো fixed state কিন্তু নেই। এখানে সবগুলোই event এবং সেগুলো properly sequence way-তে store করা। এখন আমার balance জানতে হলে এগুলো replay করতে হবে। Replay করার পরে balance হবে: ১০,০০০ - ২,০০০ + ৫০০ - ৩,৫০০ = ৫,০০০। এই জিনিসটাই কিছু আগে কিন্তু একবার করেছেন।

Event Sourcing-এর জাদু

Event sourcing জিনিসটার concept-টা একদম simple। কিন্তু implementation একটু complex। কিন্তু যেখানে প্রতিটি event বা operation আপনার জন্য important, সেখানে শুধুমাত্র এই event sourcing-ই use করা হয়। For example:

Banking sector-এ একজন user-এর প্রত্যেকটা event store করে রাখা প্রয়োজন, কারণ যেকোনো সময়ে audit বা legal requirement-এর জন্য আপনাকে প্রত্যেকটা event-এর হিসাব দিতে হয়। আর টাকার হিসাব এদিক-ওদিক হলেই bank-এর liability তৈরি হয়ে যাবে। Bank-এর reputation নষ্ট হবে। এই জন্য এই জিনিসটা খুবই important। Similar way-তে medical related application-এর জন্যও same rule apply হতে পারে।

Complete Audit Trail — কখন কী হয়েছে সব জানা যাবে। Financial system, healthcare-এ এটা must।
Temporal Query — "৩ মাস আগে balance কত ছিল?" — সহজেই বের করা যাবে।
Debug — Bug হলে event replay করে ঠিক কোথায় সমস্যা হয়েছে দেখা যাবে।
Event Replay — নতুন feature-এর জন্য পুরনো data নতুন করে process করা যাবে।

কিন্তু এখানে একটা বড় question আসতে পারে, event-এর পরিমাণ যদি ১ লাখের বেশি হয়ে যায় তখন কী হবে? প্রতিবার balance জানার জন্য ১ লাখ event replay করতে হবে? বিষয়টা কী পরিমাণ resource consume করতে পারে সেটা বুঝতেই পারছেন।
Answer হচ্ছে এটা বারবার করার প্রয়োজন হবে না। এর জন্য Snapshots use করা হয়।

Snapshots

Snapshots concept-এর সাথে already পরিচিত হওয়ার কথা। সংক্ষেপে বললে এখানে কিছু checkpoints তৈরি করে রাখা হয়, যাতে easily সেগুলো use করা যায়।

ওপরে যে problem-টার কথা বললাম, ১ লাখ event হলে কী হবে। আসলে এই ক্ষেত্রে snapshot use করা হবে। প্রতি ১০০০ event-এর state-কে aggregate-এ save করে রাখা হবে snapshot হিসেবে। এভাবে চলতে থাকবে।

তখন ১ লাখ event-এর জন্য, last snapshot এবং নতুন events-গুলো replay করলেই হয়ে যাবে। Balance জেনে যাবো।

Projection: Read Model তৈরি করুন

এখানে যেহেতু কোনো single state না। আপনি চাইলেই এটাকে direct present করতে পারবেন না। এটাকে present করার জন্য কিছু কাজে লাগবে। সেই জিনিসটা হচ্ছে Projection (বা Projector Engine) । আর এই projection-এর মাধ্যমে read optimized view তৈরি করা হয়।

Projector ব্যাকগ্রাউন্ডে Event Store থেকে আসা নতুন ইভেন্টগুলো শোনে (Event Bus/Kafka-র মাধ্যমে) এবং সরাসরি Read Database-এ pre-computed বা সাজানো ডাটা আপডেট করে দেয়

For example:

// Projector যা Read Database আপডেট করে
eventBus.on("OrderPlaced", async (event) => {
  await readDb.userDashboard.updateOne(
    { userId: event.userId },
    {
      $inc: {
        totalOrders: 1,
        totalSpent: event.amount,
      },
      $set: { lastOrderAt: event.timestamp },
    },
    { upsert: true },
  );
});

কখন ব্যবহার করবেন?

CQRS+Event Sourcing দরকার যখন:

Audit log mandatory (banking, healthcare, legal)
Complex reporting/analytics
High read/write ratio difference
Event replay দরকার হবে

দরকার নেই যখন:

Simple CRUD application
Small team, fast iteration
History রাখার দরকার নেই

বটম লাইন

CQRS আর Event Sourcing powerful কিন্তু complexity আনে। Simple CRUD-এ এটা over-engineering। কিন্তু financial system, audit trail critical এমন system-এ — এটা ছাড়া চিন্তাই করা যায় না।

আপনি চাইলে শুধু cqrs pattern use করতে পারেন, যদি application-এর scale ছোট হয়। তবে complex এপ্লিকেশন এ দুই টা জিনিস একসাথেই বেশির ভাব ক্ষেত্রেই use হয়।

CQRS বা Event Sourcing কি আপনার কাজে লেগেছে? কমেন্টে শেয়ার করুন! 👇

Day 23 - Domain-Driven Design - কোড যখন Business-এর ভাষায় কথা বলে

Monirul Islam — Mon, 28 Sep 2026 04:20:00 +0000

আপনার application এখন অনেক বড় হয়েছে। আপনি microservices বা modular monolith নিয়ে কাজ করছেন। সবকিছু ঠিকঠাকই চলছে, কিন্তু নতুন একটা সমস্যা দেখা দিলো।

Business team মিটিংয়ে বলছে, "যখন কোনো VIP Customer-এর Order confirm হবে, তখন তার Loyalty Points add করতে হবে এবং Inventory থেকে Stock reserve করতে হবে।"

কিন্তু আপনার codebase-এ গিয়ে দেখলেন VIP Customer বা Loyalty Points নামে কিছুই নেই! সেখানে আছে UserEntity, status_flag = 1, আর OrderRepository।
Business team-এর ভাষা আর developer-দের কোডের ভাষার মধ্যে বিশাল গ্যাপ। এই গ্যাপের কারণেই complex project-এ bug বেশি আসে এবং requirement বুঝতে ভুল হয়।

এই সমস্যার সমাধানই হলো DDD (Domain-Driven Design)।

Domain-Driven Design (DDD) কী?

সহজ কথায়, Domain-Driven Design (DDD) হলো সফটওয়্যার তৈরির এমন একটি অ্যাপ্রোচ, যেখানে ডাটাবেস বা ফ্রেমওয়ার্কের চেয়ে Business Domain বা ব্যবসার মূল লজিককে বেশি গুরুত্ব দেওয়া হয়।

সাধারণত আমরা ডাটাবেস টেবিল চিন্তা করে কোড লেখা শুরু করি (Data-Driven)। কিন্তু DDD-তে আমরা আগে Business-এর কাজগুলো (Domain) বুঝি এবং সেই অনুযায়ী কোড সাজাই। এর মূল লক্ষ্য হলো ডেভেলপার এবং ডোমেইন এক্সপার্টদের (business team) মধ্যে দূরত্বের অবসান ঘটানো এবং কোডকে এমনভাবে স্ট্রাকচার করা যেন তা বাস্তব জগতের business process-এর সাথে হুবহু মিলে যায়।

Ubiquitous Language: একই ভাষায় কথা বলুন

DDD-র প্রথম নিয়ম - developer আর business stakeholder একই শব্দ ব্যবহার করবে।

Business যদি বলে "Order confirm করো", codebase-এও ঠিক order.confirm() মেথড থাকবে।
Business যদি বলে "Customer", কোডে User না লিখে Customer লিখতে হবে।

এই common vocabulary-কে বলে Ubiquitous Language। যখন code এবং business একই ভাষায় কথা বলে, তখন requirement implement করা অনেক সহজ হয়ে যায়।

Bounded Context: সীমানা টানুন

একটা বড় system-এ একই শব্দের মানে ভিন্ন ভিন্ন জায়গায় ভিন্ন হতে পারে।

Sales context-এ Customer = নাম, contact, purchase history।
Shipping context-এ Customer = delivery address, preferred time।
Support context-এ Customer = ticket history, complain log।

এগুলো হলো আলাদা Bounded Context। প্রতিটা context-এ "Customer" একটু আলাদা মডেল।
এটা না বুঝলে একটা God-object তৈরি হয় - মানে ২,০০০ লাইনের একটা বিশাল User class যেখানে সব context-এর logic একসাথে ভরা থাকে। Microservices-এ সার্ভিস ভাগ করার ক্ষেত্রে এই Bounded Context-ই সবচেয়ে বড় ভূমিকা পালন করে।

Entity vs Value Object: ডেটার ধরন বুঝুন

DDD-তে object সাধারণত দুই ধরনের হয়:

১. Entity: যার একটা Unique ID আছে এবং সময়ের সাথে যার state পরিবর্তন হয়। যেমন: Order, Customer। এদের ID এক হলে properties ভিন্ন হলেও এরা একই Entity।

২. Value Object: যার কোনো ID নেই, এর value দিয়েই একে চেনা হয়। যেমন: Address, Money।

class Money {
  constructor(
    public readonly amount: number,
    public readonly currency: string,
  ) {}

  add(other: Money): Money {
    if (this.currency !== other.currency) throw new Error("Currency mismatch");
    return new Money(this.amount + other.amount, this.currency);
  }
}

Value objects সবসময় Immutable হয়।

Aggregate: Consistency-র দারোয়ান

Aggregate হলো একটা cluster of objects (Entities and Value Objects) যেটা একসাথে consistent থাকতে হবে।

যেমন, Order হলো একটা Aggregate (একে Aggregate Root-ও বলা যায়)। এর ভেতরে OrderItems, ShippingAddress (Value Object) থাকতে পারে। বাইরের কোনো class সরাসরি OrderItem-কে modify করতে পারবে না, যা করার Order-এর মাধ্যমেই করতে হবে।

class Order {
  private items: OrderItem[] = [];
  private status: OrderStatus = OrderStatus.PENDING;

  // Business logic inside the domain, not in a service!
  addItem(product: Product, quantity: number): void {
    if (this.status !== OrderStatus.PENDING) {
      throw new Error("Cannot modify a confirmed order");
    }
    this.items.push(new OrderItem(product, quantity));
  }

  confirm(): void {
    if (this.items.length === 0) {
      throw new Error("Cannot confirm an empty order");
    }
    this.status = OrderStatus.CONFIRMED;
    this.addDomainEvent(new OrderConfirmedEvent(this.id));
  }
}

Business rule কোডের ভেতরে থাকবে, Controller বা Service layer-এ নয়।

Domain Events: যা ঘটলো সেটা জানাও

যখন কোনো Aggregate-এর state change হয়, তখন সে একটা event fire করে। Event-Driven Architecture (EDA)-এর সাথে এটি চমৎকারভাবে কাজ করে।

class OrderConfirmedEvent {
  constructor(
    public readonly orderId: string,
    public readonly occurredAt: Date = new Date(),
  ) {}
}

Order.confirm() call হলে OrderConfirmedEvent fire হবে। এরপর Email module বা Inventory module যে-ই এই event শুনুক না কেন, সে তার নিজের কাজ (Bounded context-এর ভেতরের কাজ) স্বাধীনভাবে করতে পারবে।

Repository Pattern: Data Access-এর আড়াল

Domain object কীভাবে database-এ save হয়, সেটা Domain-এর জানার দরকার নেই। Domain layer থাকবে একদম pure, কোনো framework-এর dependency ছাড়া।

// Domain Layer (Pure TypeScript)
interface OrderRepository {
  save(order: Order): Promise<void>;
  findById(id: string): Promise<Order | null>;
}

Interface থাকবে Domain layer-এ, আর এর implementation থাকবে Infrastructure layer-এ।

// Infrastructure Layer
@Injectable()
export class PostgresOrderRepository implements OrderRepository {
  constructor(
    @InjectRepository(OrderSchema)
    private readonly repository: Repository<OrderSchema>,
  ) {}

  async save(order: Order): Promise<void> {
    // Convert pure Domain 'Order' to TypeORM entity and save
    const entity = this.mapToOrmEntity(order);
    await this.repository.save(entity);
  }

  // ...
}

এতে করে কালকে যদি ORM চেঞ্জও করেন, আপনার core business logic-এ এক লাইনেরও পরিবর্তন আসবে না!

বটম লাইন

DDD মানে complex architecture জোর করে চাপানো না। মানে হলো - code যেন business-এর ভাষায় কথা বলে, business rules যেন code-এ স্পষ্ট থাকে। ছোট CRUD application-এর জন্য DDD over-engineering, কিন্তু complex domain-এ এটা রক্ষাকবচ।

DDD-এর কোন concept-টা আপনার কাছে সবচেয়ে interesting লেগেছে? Entity নাকি Value Object? কমেন্টে বলুন! 👇

Day 22 — Microservices vs Monolith — Hype বাদ দিয়ে সত্যিটা বলি

Monirul Islam — Sun, 27 Sep 2026 04:20:00 +0000

আপনার application এখন ভালোভাবেই চলছে। আপনি এখন আর একা কাজ করেন না। আপনি কয়েকটি team build করেছেন। অনেকদিন ধরেই এই team building-টা চলছে। মোটামুটি ১০০-১২০ জনের team আপনারা operate করছেন।

এখন আপনার ইচ্ছা জাগল যে system-টা optimize করা দরকার। এর জন্য শুরু করলেন system monitoring। এভাবে ১ সপ্তাহ monitoring করলেন। ১ সপ্তাহ পর আপনার কাছে সব data চলে আসলো। আপনি কিছু জিনিস খেয়াল করলেন:

Feed এবং Chat related service-গুলো সবথেকে বেশি use হচ্ছে।
Post-এর write-এর থেকে read করা হচ্ছে বেশি।
Payment related service-গুলোর usage একেবারেই কম, মাসের শেষে বা প্রথমে এই service-টা use হয়।

এছাড়াও আরও কিছু জিনিস আপনি উপলব্ধি করলেন, team member-দের কাছ থেকে feedback নিলেন:

Feed related service-গুলো, post-এর সাথে সম্পৃক্ত থাকলেও, chat related service-এর কোনো connection নেই। এই কারণে অনেক performance drop হচ্ছে। Server capacity বেড়ে যাচ্ছে। বেশি user handle করা যাচ্ছে না। For example, সন্ধ্যার পরে chat service-এর usages বেড়ে যায়, এই কারণে user-রা নতুন post করতে problem face করে, অল্প একটু latency থাকে। Feed service-এ একটু problem হয়।
Development problem। Application-টা অনেক বড় হয়ে গেছে। এখন একই codebase-এ অনেক team কাজ করে। এই জন্য এটা maintain করা ঝামেলা হয়ে যাচ্ছে। Feature development-এর চেয়ে code maintain করতেই সময় চলে যাচ্ছে।
Deployment issue। Everyday নতুন নতুন feature, improvement হচ্ছে। এই অবস্থায় ছোট একটা bug fix করে deploy করলেও পুরো application build করা লাগছে।
Merge conflict নিয়মিত হচ্ছে।

এগুলো ছাড়াও আরও অনেক বিষয় আছে যেগুলো আপনি উপলব্ধি করলেন। এই কারণে system-এর performance down হচ্ছে। একটু optimize করলে profit-ও একটু বাড়ানো যাবে।

Monolith: যা দিয়ে সবাই শুরু করে

Monolith মানে সব কিছু একটা codebase-এ, একটা deployment। আপনার application-টাও কিন্তু monolith application। Server অনেকগুলো বাড়িয়েছেন কিন্তু codebase তো সেই একটাই।

Monolith application's folder structure

my-app/
  ├── auth/
  ├── orders/
  ├── payments/
  ├── notifications/
  └── main.ts

সুবিধা:

Development simple। একটা project খুললেই সব দেখা যায়।
Debugging easy।
End-to-end test সহজ।
Deploy একটাই।

সমস্যা যখন বাড়ে:

Codebase বিশাল হয়ে যায়।
একটা bug পুরো app down করে।
আলাদা আলাদা scale করা যায় না।
৫০ জন developer একই codebase-এ conflict করে।

Microservices: Small and Independent

আপনার বর্তমান সমস্যার সমাধান হচ্ছে microservice। Application-কে domain এবং use case অনুযায়ী অনেক part-এ divide করা হবে। প্রত্যেকটা part-ই হলো একেকটা microservice। এখানে প্রত্যেকটা service standalone application হিসেবে কাজ করে। Logic আলাদা, implementation আলাদা হতে পারে, infact database-ও আলাদা হতে পারে।

feed-service     → port 3001
chat-service    → port 3002
payment-service  → port 3003

সুবিধা:

Independent deploy — Payment service update করলে feed বা chat service restart না।
Independent scale — Feed page-এ বেশি traffic? শুধু feed-service scale করলেই হবে।
আলাদা team আলাদা service own করে। এতে কোড maintain করা easy হয়। Merge conflict কমে যায়।

সমস্যা:

Network latency — একটা request ৫টা service ঘুরে আসে।
Distributed transactions কঠিন।
Debugging nightmare — কোন service-এ error?
Infrastructure complexity বাড়ে অনেক।

এখানে একটা problem আছে। আগের multiple server-এর মতো। আগে তো Load Balancer use করে সেটা solve করেছিলাম। সেখানে একটা application-এর clone ছিল, problem নাই। কিন্তু এখানে Load Balancer দিয়ে কাজ হবে না।

আর এই service-গুলোর IP address সব জায়গায় দেওয়া তো possible না। তাহলে solution-টা কী? Solution-টা হচ্ছে API Gateway। API Gateway-তে এই service-গুলো connect হবে এবং একটা simple application-এর মতো behave করবে। User কিছুই বুঝতে পারবে না।

যেখানে সবচেয়ে বেশি ক্যাচাল লাগে!

Microservices মানে distributed system। আর আমি আগে বলেছি, "Distributed system is a nightmare"। কখন কোন সময় কী হবে আপনি predict-ই করতে পারবেন না। 3 body problem-এর মতো। আপনার ঘুম হারাম হয়ে যেতে পারে যেকোনো সময়।

Problems:

Partial failures — Service A চলছে, Service B down। এখন আপনি সার্ভিস B use করতে পারবেন না। এখানে scalling করা লাগতে পারে। তার জন্য আলাদা ঝামেলা।
Network timeouts — কোনর কারণে নেটওয়ার্ক slow হয়ে গেছে, এক টা পর্যায়ে timeout ও হয়ে যাচ্ছে। এখন inter-service communication করতে সমস্যা হবে ইনফ্যাক্ট হবেই না। এটা একটা সমস্যা।
Data consistency — দুই service-এ data কীভাবে consistent রাখব? এর জন্য CAP theoram আছে। এই নিয়ে সামনে আলোচনা হবে ইনশাআল্লাহ।

এই problem গুলা resolve করতে Circuit Breaker, Saga pattern, Distributed tracing — সব দরকার। এই overhead ছোট team সামলাতে পারে না। এই জন্য ছোট টিমের জন্য microservice না।

N:B: এতক্ষণে হয়তো কিছু idea করতে পেরেছেন যে microservice-এ event driven architecture কেন use করা হয়।

কখন কোনটা?

Monolith দিয়ে শুরু করুন যখন:

Startup, নতুন product, MVP।
Team size ছোট (< ১৫ জন)।
Business domain এখনো পরিষ্কার না।
Fast iteration দরকার।

Microservices যান যখন:

Product proven, scale দরকার।
Team বড় (৫০+ developer)।
স্পষ্ট bounded context আছে।
Independent deploy-এর সুবিধা cost justify করে।

Modular Monolith: Middle Ground

Monolith-এ সবকিছু তো এক জায়গাতেই থাকে। Modular monolith-এ সব code একসাথেই থাকে তবে সেগুলো module আকারে divide করা থাকে। অনেকটা microservice-এর concept-এর মতো, standalone module। এইসব module-গুলো main application-এর সাথে loosely coupled থাকে। খুব easily এই application থেকে module remove করা যায় বা অন্য কোথাও সরিয়ে নিয়ে যাওয়া যায়।

আমি personally modular monolith architecture-টা পছন্দ করি।

Folder structure of Modular Monolth:

my-app/
  ├── modules/
  │   ├── auth/      ← নিজস্ব DB schema
  │   ├── orders/    ← নিজস্ব DB schema
  │   └── payments/  ← নিজস্ব DB schema
  └── main.ts

Modular monolith-এর সবথেকে বড় সুবিধা হচ্ছে, এই module-গুলোকে gradually microservices-এ convert করা যায়। For example, order-কে আমি একটা আলাদা service-এ নিয়ে যেতে পারবো। একটা standalone application বানাবো এবং feature সবকিছু same থাকবে। At last, API Gateway-এর সাথে main application + order service connect করে দেবো। এভাবে gradually একটা modular monolith-কে microservice-এ transfer করা যায়।

বটম লাইন

Microservices Netflix, Uber-এর জন্য সঠিক — কারণ তারা সেই scale-এ। startup-এর জন্য না। Monolith দিয়ে শুরু করুন, domain বুঝুন, তারপর দরকার হলে আলাদা করুন।

আপনার current project কোনটা? পরিবর্তন করেছেন কখনো? কমেন্টে শেয়ার করুন! 👇

Day 21 - Scaling - Horizontal vs Vertical Scaling - কোনটা কখন করবেন?

Monirul Islam — Sat, 26 Sep 2026 04:20:00 +0000

আপনার build করা application-টি এতই viral হয়ে গেছে যে, এর user base lakh cross করে গেছে। এবং concurrent user লাখের কাছাকাছি। এই অবস্থায় আপনার যে server আছে, তা user-দের load নিতে পারছে না। Peak time-এ user-দের wait করতে হচ্ছে। Data inconsistency-র একটা issue দেখা দিচ্ছে। মাঝে মাঝে server crash করছে। মাঝে মাঝে database-এ data insert হচ্ছে না। অবস্থা একদম বেগতিক হয়ে গেছে।

এখন এর সমাধান হচ্ছে resource বাড়ানো। সহজ কথায় scale করা। আপনি ঠিক তাই করলেন, scale করে resource বাড়িয়ে দিলেন—user খুশি, আপনিও খুশি।

কিন্তু সমস্যা বাঁধল কিছুদিন পর। আপনার আগে যে concurrent user ছিল লাখের কাছাকাছি, সেটা 1 million ছাড়িয়ে গেল। আবার সেই আগের মতো situation তৈরি হলো। আপনি resource বাড়াতে গিয়ে দেখলেন যে, আপনার server-এর resource limit শেষ। মানে আর increase করতে পারবেন না।

এখন কী করবেন?

আসুন, এই বিষয়গুলো নিয়েই আলোচনা করি।

Vertical Scaling: A single big machine

Vertical scaling সহজভাবে বললে, আপনার machine থাকবে একটা। আমি শুধু এর CPU, memory, storage এগুলো increase করব। এই কাজটা কিন্তু already দুইবার করে ফেলেছেন। এটাই হলো vertical scaling।

For example:

Core: আগে ২, এখন ৪
Memory: আগে 8GB, এখন 16GB
Storage: আগে 50GB, এখন 100GB

সুবিধা:

Simple। Application-এ কোনো পরিবর্তন লাগে না।
Database-এর জন্য অনেক সময় সহজতম সমাধান।

সমস্যা:

একটা সীমা আছে। সবচেয়ে বড় server-ও finite। এই সম্মুখীন already হয়ে গেছেন।
Single Point of Failure - এই একটা server dead হয়ে গেলে সব বন্ধ হয়ে যাবে।
Downtime লাগতে পারে upgrade করতে।

Horizontal Scaling: Multiple Machine

Vertical scaling-এ একটা machine-এই শুধু resource increase করা হয়েছে। Horizontal scaling-এর ক্ষেত্রে এটা পুরোটাই উল্টো। এখানে resource increase করার বদলে নতুন machine introduce করা হয়। Theoretically, এই machine-এর সংখ্যা unlimited। মূলত user traffic-কে এই machine-গুলোতে distribute করে দেয়া হবে। এতে machine-এর ওপর load কমে গেলে ভালোভাবে perform করতে পারবে।

আপনি একটু চালাক আছেন, তাই আপনার মনে question জাগলো—যে ২-১টা machine-এর IP address তো আমি manually distribute করতেই পারি। কিন্তু machine বা server যদি ১০, ২০ বা তার অধিক হয়, তাহলে তো ঝামেলা বেধে যাবে!

এর solution হচ্ছে Load Balancer। Load Balancer-এর কাজ হচ্ছে user traffic-কে multiple server-এর ভেতর distribute করে দেয়া।
এখন আপনি নিশ্চিন্ত।

সুবিধা:

Theoretically unlimited scaling।
একটা server deah হলেও বাকিগুলো চলতে থাকে।
Traffic বাড়লে server বাড়ানো জয়, কমলে server কমানোও যায়।

সমস্যা:

Application-কে stateless হতে হবে।

Applicaiton with session based authentication is a Statefull apllication.

Stateless হওয়া কেন দরকার?

মনে করুন আপনার application authentication-এর জন্য session use করে।
আপনার system-এ ৩টি server আছে:

Server A
Server B
Server C

এখন user login করার জন্য login route-এ hit করলো, এটা Load Balancer (LB)-এর কাছে আসলো, তারপর LB সেটাকে Server A-তে redirect করে দিলো। Server-এ session create হলো। এই পর্যন্ত ঠিকই আছে।

এরপর login করার পর user dashboard open করলো (dashboard public user-দের জন্য restricted), dashboard-এর জন্য server-এ request গেলো। প্রথমে LB-র কাছে, LB এবার request-টাকে Server B-তে redirect করলো। Server B দেখলো যে এখানে কোনো session-ই নাই। তারমানে এ public user, একে data দেয়া যাবে না। আপনার request reject করে দিলো এবং dashboard আর load হলো না।

এখন session-based authentication যদি খুব বেশি important হয়, তাহলে এর জন্য একটা solution আছে। Session store করার জন্য একটা আলাদা database use করতে হবে। এই database Redis হতে পারে।

Redis use করার সবচেয়ে বড় reason হচ্ছে এর TTL (Time To Live) based expiration। আপনার session তো একটা নির্দিষ্ট সময়ে গিয়ে expire হয়ে যাবে। Redis আপনাকে সেটা by default-ই দিয়ে দিবে, আপনাকে manually delete করতে হবে।

Database Scaling: আলাদা চিন্তা

আপনার সামনে নতুন একটা situation তৈরি হয়ে গেছে। ১০টা server তো add করে দিলেন, কিন্তু user-কে সেই wait করতেই হচ্ছে। আপনি একটু investigate করার পর বুঝতে পারলেন যে, এখন server problem না করলেও database problem করা শুরু করে দিয়েছে।

Server-এর load distribute হলেও, database-এর load কিন্তু সেই আগের মতোই আছে। এখন database-কেও scale করা লাগবে। তবে server-এর মতো database scaling এত easy না। একটু এদিক-সেদিক হলেই আপনার পুরো system-এ সমস্যা হতে পারে, user data গায়েব হয়ে যেতে পারে। Data inconsistency দেখা দিতে পারে। এছাড়াও আরও অনেক রকম problem আছে।

Database scaling-এর ক্ষেত্রে mainly vertical scaling যতটা possible করা হয়। তারপরেও যদি problem হয়, তাহলে-

Vertical Scaling - একটাই big powerful server।
Read Replica - Read operations এর জন্য বাড়তি database server add করা।
Sharding - শুধু যখন সত্যিই দরকার। এটা নিয়ে পুরা একটা বই লিখে ফেলা যাবে।

তবে ক্ষেত্রবিশেষে caching করলেই database scaling করা লাগে না। For example, read-heavy application-এ database-এ load-ই আসবে না। Cache থেকেই সব data serve হয়ে যাবে।

Types of Scaling একসাথে

Load Shifting - Peak time-এর কাজ off-peak-এ করো। Batch jobs রাতে।
Auto Scaling - Traffic বাড়লে automatically নতুন instance, কমলে বন্ধ। AWS, GCP সব দেয়।

কোনটা করব?

পরিস্থিতি	পদ্ধতি
Database bottleneck	Vertical scaling
Web server bottleneck	Horizontal scaling
Sudden traffic spike	Auto-scaling
Budget কম	Vertical দিয়ে শুরু
High availability দরকার	Horizontal

বটম লাইন

শুরুতে Vertical scaling। সহজ, কোড পরিবর্তন লাগে না। তারপর stateless architecture বানান, তখন Horizontal scaling সহজ হয়ে যায়। Database আলাদাভাবে চিন্তা করুন।

আপনার system-এ এখন কোন scaling strategy? কমেন্টে শেয়ার করুন! 👇

Day 20 — CDN ও Edge Caching — সার্ভারকে বিশ্রাম দিন

Monirul Islam — Fri, 25 Sep 2026 04:20:00 +0000

আপনি অনেক কষ্ট করে একটি application develop করলেন। Deploy করলেন বাংলাদেশের একটি server-এ। খুব সুন্দরভাবে সবকিছু চলছিল। কিন্তু হঠাৎ করে আপনার এই application-টি viral হয়ে গেল।

এখন Australia থেকে কেউ আপনার application-টি try করতে চাইল। কিন্তু সবকিছু অনেক দেরিতে show হচ্ছে। Latency অনেক বেশি। মোটামুটি অনেক time লেগে যাচ্ছে, wait করতে হচ্ছে। HTTP কীভাবে কাজ করে, এটা বুঝতে পারলে, কেন এমন হচ্ছে তা সহজেই বুঝে যাবেন।

বাংলাদেশ থেকে Australia-র distance প্রায় ৭,৫০০ কিলোমিটার। এখন এই distance অতিক্রম করতে সবকিছু মিলিয়ে মোটামুটি 300-500ms লেগে যাবে। Content-এর size অনুযায়ী এটা কমবেশি হতে পারে। Generally, এটা বেশ অনেকটা সময়। বাংলাদেশ থেকে Australia-তে data যেতেই এই সময় লেগে যাচ্ছে। এরপর locally load হওয়ার জন্যও আরও অনেক time লাগবে। এতে user কমে যাওয়ার সম্ভাবনা থাকে।

এই latency কমানোর উপায় কী?

CDN (Content Delivery Network)।

CDN কীভাবে কাজ করে?

একটা বিষয় চিন্তা করে দেখুন, আপনি যখন বাংলাদেশ থেকে access করেন তখন কিন্তু খুব বেশি সময় লাগে না। মানে আপনি যখন server-এর কাছাকাছি থাকেন, তখন latency অনেক কম থাকে।

কোনোভাবে, এই কাজটা যদি Australia-তেও করা যেত, তাহলে latency অনেকটাই কম হতো! কিন্তু সমস্যা হচ্ছে, Australia-তে same server maintain করা একটু ঝামেলার ব্যাপার।

এই সমস্যাটার সমাধানই করে মূলত CDN।

CDN হলো একটি distributed network যেখানে বিশ্বের বিভিন্ন স্থানে server স্থাপন করা থাকে এবং এই serverগুলো একসাথে কাজ করে। CDN data store করার পর স্বয়ংক্রিয়ভাবে সেই Data সব সার্ভারে Replicate হয়ে যাবে এবং সেখান থেকেই পরবর্তীতে ডাটা সার্ভ হবে।

Australia থেকে request করা user Australia-র সব থেকে কাছের সার্ভার থেকে এই ডাটা পাবে।

Setup করার পর latency 30-50ms-এর মধ্যে চলে আসবে। অর্থাৎ, প্রায় 10x faster!

বলে রাখা ভালো CDN শুধুমাত্র cached data serve করে। আর আগের একটা আর্টিকেলে বলেছি যে data cache করা আছে সেই data change করলে cache invalidation করে নতুনভাবে data cache করতে হয়।

কী Cache করা যায়?

আপনি চাইলেই সব ডাটা ক্যাশ করতে পারবেন না। কারণ এক্ষেত্রে Inconsistency দেখা দিতে পারে। Caching নিয়ে ১৫ এবং ১৬ নম্বর আর্টিকেলে বিস্তারিত আলোচনা আছে। ইতিমধ্যেই জেনে থাকার কথা।

CDN-এ মূলত নিচের এই জিনিসগুলো ক্যাশ করা হয়ে থাকে:

Static assets — images, CSS, JS, fonts। এগুলো সহজেই cache করা যায়।
HTML pages — SSG (Static Site Generation) site-এ পুরো HTML cache করা যায়।
API responses — read-heavy, rarely changing data।

Cache Headers: Browser আর CDN-কে বলুন

Cache-Control: public, max-age=31536000, immutable

public — CDN cache করতে পারবে।
max-age=31536000 — ১ বছর cache।
immutable — এই সময়ে content পাল্টাবে না।

Cache-Control: no-cache

এটা মানে cache করা যাবে না। Login page, checkout page-এ এটা দিন।

CDN কোথায় ব্যবহার করবেন?

Static Assets — /assets/logo.png, /dist/bundle.js — এগুলো CDN-এ রাখুন।
Next.js / Vercel — Edge-এ render করে। দুর্দান্ত performance।
Image Optimization — Cloudinary, ImageKit — images resize, compress, format convert করে deliver করে।

Cache Invalidation on CDN

"Cache invalidation is a nightmare."

CDN-এ file update করলে পুরানো cache আটকে থাকবে।

সমাধান — Cache Busting। File-এর URL-এ hash দিন:

/assets/bundle.a3f9c2.js

Content পাল্টালে hash পাল্টাবে। Browser/CDN নতুন file নামাবে।

বটম লাইন

CDN শুধু performance না — cost কমায়, availability বাড়ায়, security দেয়। Static assets CDN ছাড়া রাখা মানে unnecessary origin server load। আজই Cloudflare বা AWS CloudFront দিয়ে setup করুন।

আপনার project-এ CDN আছে? না থাকলে কেন না? কমেন্টে জানান! 👇

Day 19 — Real-Time Communications | WebSockets vs SSE vs Long Polling

Monirul Islam — Thu, 24 Sep 2026 04:20:00 +0000

আমার development journey শুরু হয়েছিল PHP দিয়ে। আর স্বাভাবিকভাবেই জানেন যে PHP দিয়ে data fetch করাতে হলে প্রত্যেক বার HTTP request করতে হতো। তখন আমি first time Facebook-এর messenger-এর chatting feature দেখে অবাক হয়েছিলাম। কোনো reload ছাড়াই message send এবং receive হচ্ছে।

এই বিষয় টা নিয়ে একটু research করার পরে জানতে পারি এইটা asynchronous communication। Page reload ছাড়াই server request পাঠানো যায়। এইটা মূলত করা HTTP request দিয়ে, যেমন এখন আমরা fetch বা axios দিয়ে করি।

কিন্তু problem হচ্ছে, page reload ছাড়া অপর সাইডে message receive হয় না। একটু বিস্তারিত বলি, মনে করুন আপনি আপনার friend-কে message দিলেন, এখন এই http বা axios দিয়ে server-এ message দিলেন। এখন আপনার friend যতক্ষণ না তার page reload করছে ততক্ষণ এই message receive হবে না।

কিন্তু আমি যেটা দেখেছিলাম, সেটা কিন্তু সম্পূর্ণ achieve করা হয়নি। Just ৫০% achieve হয়েছে মাত্র। এই জন্য আরেকটু research করি। তখন জানতে পারি আমি এতক্ষণ যেটা try করছিলাম, সেটা হচ্ছে ১-way communication কিন্তু আমাদের দরকার ২-way communication। এটা নিয়ে deep dive করলে জানতে পারি যে ২-way communication-এর জন্য WebSocket use করা হয়। আর WebSocket real-time-এ communicate করতে পারে। Reload করা ছাড়াও message send এবং receive করা যায়।

WebSocket কী?

WebSocket হলো একটা communication-এর method যেখানে server এবং client always connected থাকে। এই connection close হয় না। Typical HTTP request-এ client-এর কিছু দরকার হলে, server-এ request পাঠায় তখন connection start হয়, data receive হয়ে গেলে এই connection close হয়ে যায়। কিন্তু WebSocket-এ এই connection-টা close হয় না। Always connected থাকে।

WebSocket-এর use case ওপরের কথাতেই বুঝে যাওয়ার কথা। এ ছাড়াও আরও অনেক use case আছে।

WebSocket-এর সমস্যা

মনে করুন, একটা গেমের leaderboard। এখানে কোন player-এর position কত সেটা live দেখাবে। এখানে যে দেখবে, সে হচ্ছে client। এখন আপনার কাছে প্রশ্ন, "Client তো শুধু দেখছে, সে আর input দিচ্ছে না। তাহলে এখানে যদি WebSocket use করি তাহলে কি ভালো হবে?"

উত্তর দেওয়ার আগে একটা জিনিস বোঝার চেষ্টা করি। WebSocket ২-way communication-এর জন্য use হয়। কিন্তু এখানে লাগছে ১-way। Server শুধু data push করবে। Client end থেকে data push করার দরকার নেই। তাহলে এখানে WebSocket use করলে কিছু waste হবে। Resource-এর proper use হবে না। তাহলে মোদ্দা কথা হচ্ছে, WebSocket ideal solution না। তাহলে solution-টা কী?

Solution-এ যাওয়ার আগে, এই টাইপের real-time communication-এর জন্য অনেকগুলো method আছে।

Real Time Communication Methods

Short Polling

এই method-এ, একটা সময় (short time) পর পর server-এ request পাঠিয়েই যাবে এবং data update করবে। নিচের example-টা দেখুন:

setInterval(async () => {
  const data = await fetch("/api/messages");
}, 2000); // প্রতি ২ সেকেন্ডে

এখানে প্রতি ২ সেকেন্ড পর পর server-এ request পাঠাচ্ছে কোনো message আছে কিনা। এই method-টা ভালোই তবে এখানে কিছু problem আছে। যেমন,
যদি server-এ নতুন কোনো message আসেনি, তাহলে কি request করার দরকার আছে? নেই। কিন্তু এই method-এ এটা হবে। Server-এ নতুন কোনো message আছে কিনা তা নিয়ে এই method-এর কোনো মাথাব্যথা নেই। এই method-এ request প্রতি ২ সেকেন্ড পর পর যেতেই থাকবে।
এখন এই unnecessary request-এর জন্য server-এ load বাড়বে + bandwidth-ও নষ্ট হবে। বিষয়টা মনে হতে পারে খুব একটা problematic না। কিন্তু যখন user ১ মিলিয়নে চলে যাবে তখন এই ২ সেকেন্ডের unnecessary request আপনার server down হওয়ার main reason হবে।

Long Polling: একটু চালাক

Long Polling, Short Polling-এর থেকে একটু চালাক। Short Polling তো interval পর পর request দিচ্ছে। কিন্তু Long Polling-এ server বলে, "তুমি আমার কাছে request দাও, দিয়ে তুমি wait করো, যখনই নতুন data আসবে তখন আমি তোমাকে response করব। তারপর তুমি যা খুশি করো।" নিচের example দেখুন:

async function poll() {
  const data = await fetch("/api/messages/wait"); // Server hold করে রাখে
  process(data);
  poll(); // আবার শুরু
}

এটা Short Polling-এর problem কিছুটা solve করলেও নতুন problem নিয়ে আসে। যেমন, এই method server connection close করে না। আর close না করলে সেই connection-এর data RAM-এ store করে রাখে। এখন আপনার system concurrently ১০০০ user request handle করতে পারে। কিন্তু worst case-এ এই ১০০০ user-ই একই সাথে request করল। তখন কী হবে? আপনার server-এর memory শেষ, এর মানে পুরা server crash করবে। এ ছাড়াও client side-এও problem তৈরি হওয়ার possibility আছে।

এটাকে অনেকটা real-time-এর মতো মনে হলেও technically ওই simple HTTP-কেই একটু logic দিয়ে use করা হচ্ছে। বিষয়টা অনেকটা এই রকম—খেজুরের রস জ্বাল দিয়ে গুড় তৈরি করা।

WebSockets: Two-way Communication

WebSocket জিনিসটা কী সেটা তো already বুঝেই গেছেন। WebSocket HTTP protocol use করে না বললেই চলে। WebSocket communication-এ TCP protocol use করে। WebSocket শুধুমাত্র connection-এর জন্য একদম প্রথমে HTTP request send করে। Connection হয়ে গেলে WebSocket TCP-এর মাধ্যমে data transfer করে থাকে। নিচের example-টা দেখুন:

// Server
const wss = new WebSocketServer({ port: 8080 });
wss.on("connection", (ws) => {
  ws.on("message", (message) => {
    // সবাইকে broadcast
    wss.clients.forEach((client) => client.send(message));
  });
});

// Client
const ws = new WebSocket("ws://localhost:8080");
ws.onmessage = (event) => console.log(event.data);
ws.send("Hello!");

WebSocket জিনিসটা বাকিগুলোর থেকে একটু complex, reason-টা বুঝেই গেছেন। বাকিগুলোতে ১-way communication হয় আর এখানে ২-way communication।

কখন WebSocket ব্যবহার করবেন

Chat application
Multiplayer game
Collaborative editing (Google Docs)
Live trading platform

সহজভাবে বললে, যেখানে client এবং server দুই দিক থেকেই real-time input এবং output দরকার তখন এই WebSocket use করা হয়।

Server-Sent Events (SSE): One-way Push

একটা ছোট question করি, আমার যদি শুধু ১-way communication লাগে—মানে এখানে server শুধু input দিবে বা নতুন data show করাবে real-time-এ, কিন্তু user-এর দিক থেকে কোনো input-এর দরকার হবে না, তখন কি WebSocket use করাটা ভালো হবে? ওপরে ঠিক এই টাইপের একটা problem-এর কথা বলেছিলাম।

এই problem-টা address করার জন্য আসে Server-Sent Events (SSE)। এই method-এ server client-এ data push করে আর client সেই data receive করে থাকে। Server-এ যখনই কোনো নতুন data আসে তখন server নতুন data-কে stream করে দেয় আর client সেটা receive করে use করে। নিচের example-টা দেখুন:

// Server (NestJS)
@Sse('events')
sendEvents(): Observable<MessageEvent> {
  return interval(1000).pipe(
    map(() => ({ data: { time: new Date().toISOString() } }))
  );
}

// Client
const source = new EventSource('/api/events');
source.onmessage = (event) => console.log(event.data);

কখন SSE ব্যবহার করবেন

Live notifications
News feed
Progress updates
Stock prices

SSE ওই টাইপের problem-এর জন্য better, যেখানে শুধুমাত্র server থেকে client-এ data আসে।

এখন ওপরে যে problem-টার কথা বলেছিলাম, আপনার মতে কোন method-টা use করলে better হবে?

সংক্ষেপে কোনটা কখন?

পরিস্থিতি	Solution
Simple notification	SSE
Chat, game	WebSocket
Legacy system	Long Polling
Simple polling OK	Short Polling

Real Life Example

সিনারিও:

একটি ব্লগের আর্কিটেকচারের কথা চিন্তা করুন।

ইউজার ফ্রন্টএন্ডে একটি নতুন পোস্ট তৈরি করল। এই সিস্টেমে ব্যবহার করা হয়েছে CQRS Pattern।
ফ্লো-টি কিছুটা এমন:
Frontend -> Post Service -> Write DB-তে Insert -> Kafka-তে Event Publish

এর পর Query Service ওই Event রিসিভ করে Read DB-তে পোস্টটি সেভ করে।

যেহেতু Read এবং Write-এর জন্য দুটো আলাদা সার্ভিস ও ডাটাবেস কাজ করছে, তাই ডাটা দুটো ডাটাবেসে সিঙ্ক (Sync) হতে কিছুটা সময় লাগে।

এখন ফ্রন্টএন্ডে ইউজার পোস্ট ক্রিয়েট করার পর পরই যদি হোম পেজে গিয়ে সব পোস্ট ফেচ করতে চায়, তবে সিঙ্ক হতে সময় লাগার কারণে পুরানো ডাটা বা স্টেল ডাটা চলে আসতে পারে, তাই না?

প্রশ্ন হলো: রিয়েল-টাইমে লেটেস্ট ডাটা পাওয়ার জন্য এবং রিয়েল-টাইমে সব ইউজারের হোম পেজে সেই পোস্ট দেখানোর জন্য ফ্রন্টএন্ডে কীভাবে হ্যান্ডেল করবেন? আপনার সলিউশন কী—WebSocket নাকি অন্য কিছু?

সলিউশন:

এই সিনারিওতে:

Long Polling: বিবেচনা করা যাবে না, কারণ ডাটা একদম রিয়েল-টাইমে দেখাতে হবে।
Short Polling: অযথা একের পর এক অনর্থক API কল করে সার্ভারে লোড বাড়াবে।
WebSocket: এখানে Overkill । কারণ WebSocket Bidirectional যোগাযোগের জন্য ব্যবহৃত হয়। কিন্তু আমাদের সিনারিওতে ফ্রন্টএন্ডের কাজ শুধু সার্ভার থেকে রিয়েল-টাইমে ডাটা রিসিভ করা, ক্লায়েন্ট থেকে ব্যাকগ্রাউন্ডে কিছু পাঠানোর দরকার নেই।
Server-Sent Events (SSE): এটাই হলো সবচেয়ে সেরা অপশন! এই মেথডে সার্ভার প্রয়োজন অনুযায়ী রিয়েল-টাইমে ফ্রন্টএন্ডে ডাটা পুশ করবে আর ফ্রন্টএন্ড শুধু ডাটা রিসিভ করে স্ক্রিনে দেখাবে।

যেহেতু রিড ও রাইটের জন্য দুটো আলাদা সার্ভিস রয়েছে, ফ্রন্টএন্ডে কখন ডাটা পাঠাব তা নিয়ে আমাদের সামনে দুটো অপশন থাকে:

অপশন ১: write database-এ ডাটা ইনসার্ট হওয়ার সাথে সাথেই SSE-এর মাধ্যমে ফ্রন্টএন্ডে ডাটা পুশ করে দেওয়া।
অপশন ২: write database-এ ডাটা sync হওয়া পর্যন্ত অপেক্ষা করা, তারপর ফ্রন্টএন্ডে ডাটা পাঠানো।

দুটো অপশনেরই জটিলতা ও কাজের ধরণ আলাদা। যেমন, অপশন ১-এ sync হওয়ার আগ পর্যন্ত সাময়িক কিছু সময়ের জন্য Inconsistency থাকতে পারে। তবে উপরের অপশনগুলোর মধ্যে SSE-ই সবচেয়ে কার্যকর সলিউশন।

(বি: দ্র: আমরা চাইলে Optimistic Way-তেও ডাটা পাঠাতে পারি, তবে সেক্ষেত্রে একটা Rollback Mechanism রাখতে হবে।)

বটম লাইন

Real-time-এর জন্য WebSocket বা SSE mandatory কিছু না। কোনটা use করতে হবে সেটা totally depend করবে আপনার application কী চাচ্ছে। Requirement-এর ওপর depend করেই decision নিতে হবে। এমনও case আছে যেখানে Short Polling-টাই best solution। For example, Log Aggregations করার ক্ষেত্রে। আপনি ২৪ ঘণ্টার interval দিয়ে log aggregate করতে পারেন। ওই situation-এ Short Polling সেরা perform করবে। তাই আপনার requirement কী সেটা আগে ঠিক করুন, তারপর decision নিন।

আপনার প্রজেক্টে কোনটা ব্যবহার করেছেন? কোনো Challenge ছিল? কমেন্টে শেয়ার করুন! 👇

Day 17 — Message Broker — RabbitMQ vs Kafka

Monirul Islam — Wed, 23 Sep 2026 04:20:00 +0000

মনে করুন, একটি ই-কমার্স অ্যাপ্লিকেশন। কোনো ইউজার যখন একটি অর্ডার প্লেস করে, তখন ব্যাকএন্ডে একগুচ্ছ কাজ সম্পন্ন করতে হয়:

কাস্টমারকে অর্ডার কনফার্মেশন ইমেইল পাঠাতে হবে।
কনফার্মেশন SMS পাঠাতে হবে।
ইনভেন্টরি বা স্টক আপডেট করতে হবে।
অ্যানালিটিক্স ডাটা আপডেট করতে হবে।

এই সবগুলো কাজ যদি অর্ডার হিট হওয়ার সাথে সাথেই সিঙ্ক্রোনাসলি (Synchronously) করতে চাই, তবে বেশ কিছু বড় সমস্যার মুখোমুখি হতে হবে:

রেসপন্স টাইম অনেক বেশি বেড়ে যাবে এবং ইউজারকে স্ক্রিনে ওয়েট করে বসে থাকতে হবে।
৩র্ড পার্টি ইমেইল বা SMS সার্ভিস ডাউন থাকলে পুরো অর্ডারটিই ফেল (Fail) মারবে।
ডাটাবেসের মধ্যে ইনকনসিস্টেন্সি (Inconsistency) তৈরি হতে পারে।

এখন নিজেকে একটা প্রশ্ন করুন—ইউজার যখন পে পেজের "Confirm Order" বাটনে ক্লিক করে, তখন কি সে সাথে সাথে ইমেইল পাওয়া পর্যন্ত অপেক্ষা করতে চায়? নাকি ১ সেকেন্ডের মধ্যে "Order Successful" মেসেজ স্ক্রিনে দেখতে চায়?

অবশ্যই ইউজার সাথে সাথে রেসপন্স দেখতে চায়! ইমেইল বা SMS ১ মিনিট পরে গেলেও কাস্টমারের কোনো সমস্যা নেই।

এই যে ব্যাকগ্রাউন্ডে ভারী কাজগুলোকে সরিয়ে দিয়ে ইউজারকে দ্রুত রেসপন্স দেওয়া—এই সমস্যার সবচেয়ে চমৎকার সমাধান হলো Message Broker।

Message Broker কী? 📬

Message Broker ব্যাপারটিকে একটি পোস্ট অফিসের সাথে তুলনা করা যেতে পারে।

আগে দূরে কোনো চিঠি বা বার্তা পৌঁছাতে পোস্ট অফিস ব্যবহার করা হতো। আপনি পোস্ট বক্সে চিঠি ফেলে দিয়ে চলে আসতেন এবং নিজের অন্যান্য কাজ শুরু করে দিতেন—চিঠি গন্তব্যে পৌঁছানো পর্যন্ত আপনি পোস্ট অফিসে দাঁড়িয়ে থাকতেন না!

Message Broker ঠিক একই ধারণায় কাজ করে। মূল অ্যাপ্লিকেশন সার্ভিসটি মেসেজ ব্রোকারের কাছে একটি মেসেজ (বা ইভেন্ট) পুশ করে দিয়ে সাথে সাথে ইউজারকে রেসপন্স জানিয়ে দেয়। পরবর্তীতে ব্যাকগ্রাউন্ডের অন্যান্য Consumer সার্ভিসগুলো সেই মেসেজটি রিসিভ করে আস্তেধীরে প্রসেস করতে থাকে।

বর্তমানে ব্যাকএন্ড ইঞ্জিনিয়ারিংয়ে দুটি মেসেজ ব্রোকার সবচেয়ে বেশি ব্যবহৃত হয়: RabbitMQ এবং Apache Kafka।

RabbitMQ: Smart Broker, Dumb Consumer 🐇

RabbitMQ হলো একটি ঐতিহ্যবাহী ও বহুল ব্যবহৃত Message Queue সিস্টেম। এটি মূলত AMQP (Advanced Message Queuing Protocol) স্ট্যান্ডার্ড অনুসরণ করে।

এর মেকানিজম বেশ সহজ—এটি Push-based Model মেনে চলে। প্রডিউসার মেসেজ পাঠালে ব্রোকার নিজে থেকে কনজিউমারের কাছে মেসেজ পুশ করে। কনজিউমার কাজ শেষে Acknowledgment (ACK) পাঠালে ব্রোকার কিউ থেকে মেসেজটি চিরতরে মুছে ফেলে।

💡 কখন RabbitMQ ব্যবহার করবেন?

Task Queue & Background Jobs: ইমেইল পাঠানো, ছবি/ভিডিও প্রসেসিং, PDF রিপোর্ট জেনারেট করার মতো কাজের জন্য।
Complex Message Routing: নির্দিষ্ট শর্তে মেসেজ পাঠাতে চাইলে (যেমন: "শুধু VIP কাস্টমারদের প্রাইওরিটি ইমেইল কিউতে পাঠাও")।
Guaranteed Delivery: প্রতিটি মেসেজ যেন মিস না হয় এবং নিখুঁতভাবে অন্তত একবার প্রসেস হয়ে মুছে যায়।

Apache Kafka: Dumb Broker, Smart Consumer 🚂

Apache Kafka কিন্তু সাধারণ Message Queue নয়—এটি একটি Distributed Event Streaming Platform।

ক্যাফকা মেসেজকে মুছে ফেলার বদলে ডিস্কে একটি Append-only Commit Log হিসেবে সংরক্ষণ করে রাখে। প্রডিউসার ইভেন্ট রাইট করে যায়, আর কনজিউমার নিজের অফসেট (Offset) ট্র্যাক করে নিজের গতিতে ডাটা রিড (Pull Model) করতে থাকে। মেসেজ পড়ার পরও ক্যাফকা থেকে ডাটা মুছে যায় না (নির্ধারিত Retention সময় পর্যন্ত সংরক্ষিত থাকে)।

💡 কখন Apache Kafka ব্যবহার করবেন?

High Volume Real-time Event Streaming: প্রতি সেকেন্ডে লাখ লাখ ইভেন্ট বা লগ প্রসেস করতে হলে (যেমন: উবার রাইড ট্র্যাকিং, ক্রেডিট কার্ড ফ্রড ডিটেকশন)।
Message Replayability: পুরানো ইভেন্ট আবার নতুন করে প্রসেস বা রিঅ্যালাইজ করার প্রয়োজন হলে।
Multiple Independent Consumers: একই ইভেন্ট স্ট্রিম থেকে আলাদা আলাদা মাইক্রোসার্ভিস (Analytics, Fraud Detection, Notification) স্বাধীনভাবে ডাটা রিড করতে চাইলে।

RabbitMQ vs Apache Kafka: মুখোমুখি তুলনা ⚖️

বৈশিষ্ট্য	RabbitMQ 🐇	Apache Kafka 🚂
আর্কিটেকচার টাইপ	Traditional Message Queue	Distributed Event Streaming Log
ডাটা মডেল	Queue (Message প্রসেস হলে মুছে যায়)	Log Stream (মেসেজ ডিস্কে সেভ থাকে)
মেসেজ ডেলিভারি	Push Model (Broker → Consumer)	Pull Model (Consumer ← Broker)
Throughput	হাজার হাজার মেসেজ/সেকেন্ড	লাখ লাখ মেসেজ/সেকেন্ড
Message Routing	অত্যন্ত শক্তিশালী (Exchange, Routing Keys)	সিম্পল (Topic & Partition ভিত্তিক)
Replayability	সাপোর্ট করে না (ACK পেলে ডিলিট)	চমৎকার (Offset পিছিয়ে আবার পড়া যায়)

Real-World Example: অর্ডার প্রসেসিং ফ্লো

RabbitMQ ফ্লো:
1. ইউজার অর্ডার দিল → Order Service মেসেজ পাঠাল RabbitMQ-তে → ইউজারকে সাথে সাথে Success রেসপন্স দেওয়া হলো।
2. ব্যাকগ্রাউন্ডে Email Worker বা SMS Worker মেসেজ পিক করল → ইমেইল পাঠিয়ে দেওয়ার পর RabbitMQ মেসেজটি ডিলিট করে দিল।
Kafka ফ্লো:
1. ইউজার রাইড বুক করল → Ride Service Kafka Topic (ride-events)-এ ইভেন্ট রাইট করল।
2. Location Tracker Service, Billing Service, এবং Analytics Engine—তিনটি স্বাধীন সার্ভিস একই সাথে ক্যাফকা টপিক থেকে প্যারালালি ডাটা রিড করে নিজেদের কাজ সম্পন্ন করল।

বটম লাইন

RabbitMQ এবং Kafka দুটিই অসাধারণ প্রযুক্তি—তবে তারা ভিন্ন সমস্যার সমাধান করে। যদি আপনার নির্দিষ্ট কাজ প্রসেস করার জন্য নির্ভরযোগ্য Task Queue দরকার হয় যেখানে মেসেজ প্রসেস হয়ে মুছে গেলেই চলে, তবে RabbitMQ বেছে নিন। আর যদি আপনার প্রতি সেকেন্ডে বিশাল আকারের ইভেন্ট স্ট্রিম প্রসেস ও অ্যানালিটিক্সের প্রয়োজন হয়, তবে Apache Kafka হলো সেরা পছন্দ।

আপনার প্রজেক্টে ব্যাকগ্রাউন্ড টাস্ক বা ইভেন্ট প্রসেস করার জন্য কোন মেসেজ ব্রোকার ব্যবহার করছেন? কমেন্টে জানান! 👇