Farhan.dev
~/portfolio/masterclass/system-design
14 Advanced Topics + 8 Simulators
Commercial-Ready Masterclass বাংলা + English Terms 8 Interactive Simulators

সিস্টেম ডিজাইন মাস্টারক্লাস (System Design Architecture)

ফান্ডামেন্টাল থেকে শুরু করে হাইপার-স্কেল প্রোডাকশন আর্কিটেকচার পর্যন্ত — বাস্তব উদাহারণ (Daraz, bKash, Netflix, Facebook, AWS), আর্কিটেকচার ডায়াগ্রাম, ট্রেড-অফ বিশ্লেষণ এবং লাইভ ভিজ্যুয়াল সিমুলেশনের মাধ্যমে সম্পূর্ণ গাইড।

14
Core Modules
8
Live Simulators
25+
Real Case Studies
100%
Interview Ready

১. Scalability ও স্কেলিং অ্যাপ্রোচ

Vertical Scaling (Scale Up) vs Horizontal Scaling (Scale Out)

Scalability কী এবং কেন জরুরি?

Scalability হলো এমন এক সক্ষমতা যার মাধ্যমে কোনো সিস্টেমের ব্যবহারকারী (Users), ট্রাফিক (Traffic) কিংবা কাজের পরিমাণ (Workload) নাটকীয়ভাবে বৃদ্ধি পেলেও সিস্টেমটি ক্র্যাশ না করে নির্বিঘ্নে ও নির্ভরযোগ্যভাবে সার্ভিস চালিয়ে যেতে পারে।

বাস্তব উদাহরণ: Daraz 11.11 বা ঈদের কেনাকাটা

স্বাভাবিক দিনে আপনার ই-কমার্স সাইটে হয়তো ১০,০০০ ভিজিটর থাকে। কিন্তু ১১.১১ বা ঈদের ক্যাম্পেইনে একসাথে ১০,০০,০০০ (১০ লাখ) ভিজিটর হিট করে। সিস্টেম যদি এই বর্ধিত লোড হ্যান্ডেল করতে পারে তবেই সেটি Scalable। অন্যথায় সাইট "504 Gateway Timeout" দিয়ে বন্ধ হয়ে যাবে।

স্কেলিং-এর প্রধান দুটি অ্যাপ্রোচ

বৈশিষ্ট্য Vertical Scaling (Scale Up) ⬆️ Horizontal Scaling (Scale Out) ➡️
মূল নীতি একটি নির্দিষ্ট সার্ভারকে বেশি শক্তিশালী করা (যেমন: 4 CPU 8GB RAM ➔ 64 CPU 256GB RAM)। সার্ভারের শক্তি না বাড়িয়ে পাশাপাশি আরও একাধিক সার্ভার যোগ করা (যেমন: ১টি সার্ভার ➔ ১০টি সার্ভার)।
খরচ (Cost) একটি নির্দিষ্ট সীমার পর হাই-এন্ড সার্ভারের খরচ বহুগুণ বেড়ে যায়। সাধারণ কমদামী ক্লাউড সার্ভার (Commodity Hardware) ব্যবহার করে খরচ নিয়ন্ত্রণ করা যায়।
আর্কিটেকচার জটিলতা খুবই সহজ; কোড বা অ্যাপের স্ট্রাকচার পরিবর্তন করতে হয় না বললেই চলে। মাঝখানে Load Balancer লাগে, সার্ভিসকে Stateless বানাতে হয়।
সীমাবদ্ধতা (Hard Limit) মাদারবোর্ড এবং হার্ডওয়্যারের ফিজিক্যাল লিমিটেশন থাকে (Single Box Limit)। তাত্ত্বিকভাবে অসীম (Unlimited); ট্রাফিক অনুযায়ী যতো খুশি সার্ভার বাড়ানো/কমানো যায়।
SPOF ঝুঁকি একটাই সার্ভার; সেটি ডাউন হলে পুরো সিস্টেম অফলাইন (Single Point of Failure)। একটি বা দুটি সার্ভার ক্র্যাশ করলেও বাকিগুলো চালু থাকে (Fault Tolerant)।

২. Load Balancing ও অ্যালগরিদম

Traffic Distribution, Layer 4/7 & Health Checks

Load Balancer কী?

যখন আপনার ব্যাকএন্ডে একাধিক সার্ভার থাকে, তখন কোনো ইউজার সরাসরি সার্ভারে কানেক্ট না হয়ে মাঝখানের একটি ট্রাফিক কন্ট্রোলারের কাছে রিকোয়েস্ট পাঠায়। এই কম্পোনেন্টটিকে Load Balancer বলা হয়। এর মূল দায়িত্ব হলো ইনকামিং ট্রাফিককে সার্ভারগুলোর মধ্যে সুষমভাবে ভাগ করে দেওয়া যাতে কোনো একক সার্ভার ওভারলোডেড না হয়।

Users ───▶ [ Load Balancer ] ───┬───▶ Server 1 (Health: OK) ├───▶ Server 2 (Health: OK) └───▶ Server 3 (Health: OK)

জনপ্রিয় Load Balancing অ্যালগরিদমসমূহ

  • Round Robin: একের পর এক ধারাবাহিকভাবে রিকোয়েস্ট পাঠায় (Req 1 ➔ S1, Req 2 ➔ S2, Req 3 ➔ S3, Req 4 ➔ S1)। সবগুলো সার্ভারের ক্ষমতা সমান হলে এটি চমৎকার কাজ করে।
  • Least Connections: যে সার্ভারে বর্তমান অ্যাক্টিভ কানেকশনের সংখ্যা সবচেয়ে কম, নতুন রিকোয়েস্টটি সেখানে পাঠানো হয়। দীর্ঘমেয়াদী রিকোয়েস্ট (যেমন: ফাইল আপলোড, ভিডিও স্ট্রিম)-এর ক্ষেত্রে এটি আদর্শ।
  • Weighted Round Robin: বেশি শক্তিশালী সার্ভারকে বেশি ওজন (Weight) দেওয়া হয় (যেমন: S1 (Weight 3), S2 (Weight 1) ➔ S1 পাবে ৩টি রিকোয়েস্ট প্রতি ১টি S2-এর জন্য)।
  • IP Hash: ইউজারের IP অ্যাড্রেসকে হ্যাশ করে নির্দিষ্ট সার্ভার নির্ধারণ করা হয়। ফলে একই ইউজার সবসময় একই সার্ভারে পৌঁছাতে পারে (Sticky Session-এর ক্ষেত্রে কাজে লাগে)।
Health Check মেকানিজম

লোড ব্যালেন্সার প্রতি ৫ বা ১০ সেকেন্ড পর পর ব্যাকএন্ডের প্রতিটি সার্ভারে একটি হালকা পিং (`GET /health`) পাঠায়। কোনো সার্ভার যদি ৩ বার ফেইল করে, লোড ব্যালেন্সার স্বয়ংক্রিয়ভাবে ট্রাফিক পাঠানো বন্ধ করে দেয় এবং সুস্থ সার্ভারগুলোতে ট্রাফিক ঘুরিয়ে দেয়।

৩. Stateless Service ও সেশন ম্যানেজমেন্ট

Why Memory State Breaks Horizontal Scaling & How Redis Solves It

Stateless বনাম Stateful আর্কিটেকচার

Stateless Service মানে হলো কোনো সার্ভার তার নিজস্ব লোকাল মেমোরি বা RAM-এ ইউজারের সংবেদনশীল স্টেট (যেমন: লগইন সেশন, শপিং কার্ট) সংরক্ষণ করে রাখে না। প্রতিটি রিকোয়েস্টে প্রয়োজনীয় সমস্ত তথ্য (JWT টোকেন ইত্যাদি) উপস্থিত থাকে, অথবা স্টেট একটি সেন্ট্রালাইজড ডাটাবেজ/ক্যাশে সংরক্ষিত থাকে।

মারাত্মক ভুল: মেমোরিতে সেশন রাখা (Sticky Trap)

ধরুন ইউজার Rahim লগইন করলো Server-1 এ। সার্ভার-১ তার র‍্যামে সেশন সেভ রাখলো। ৫ সেকেন্ড পর Rahim যখন 'Buy Now' বাটনে চাপ দিলো, লোড ব্যালেন্সার রিকোয়েস্ট পাঠালো Server-2 এ! Server-2 রহিমকে চেনে না, ফলে রহিম হঠাৎ লগআউট হয়ে গেলো!

সঠিক সমাধান: সেশন বা স্টেটকে একটি সেন্ট্রালাইজড ইন-মেমোরি স্টোর (যেমন: Redis Cluster)-এ রাখা। এর ফলে যেকোনো সার্ভারে রিকোয়েস্ট গেলেই সে Redis থেকে দ্রুত সেশন ভেরিফাই করে নিতে পারে।

User Req 1 ───▶ Server 1 ──┐ ├───▶ [ Central Redis Cluster ] (Session: Rahim) User Req 2 ───▶ Server 2 ──┘

৪. Database Replication ও হাই-অ্যাভেইলেবিলিটি

Primary-Replica Architecture, Read Scaling & Replication Lag

কেন Database Replication প্রয়োজন?

বাস্তব অ্যাপ্লিকেশনগুলোতে সাধারণ দিনে রিড (Read - ডাটা দেখা) অপারেশনের পরিমাণ রাইট (Write - ডাটা যোগ বা আপডেট) এর চেয়ে ১০ থেকে ১০০ গুণ বেশি হয়। একক ডাটাবেজে সব রিকোয়েস্ট পাঠালে ডাটাবেজ স্লো হয়ে যায়।

  • Primary (Master) DB: শুধু Write, Update, Delete অপারেশনগুলো হ্যান্ডেল করে। এরপর ডাটা পরিবর্তনগুলো বাইনারি লগ (WAL / Binlog) দিয়ে রেপ্লিকাতে পাঠায়।
  • Read Replicas (Slaves): একাধিক রিড রেপ্লিকা কেবল ইউজারের রিড কোয়েরি হ্যান্ডেল করে। ফলে রিড ট্রাফিক যত বাড়ে, তত বেশি রেপ্লিকা যুক্ত করে স্কেল করা যায়।
  • Failover: প্রাইমারি ডাটাবেজ ক্র্যাশ করলে রেপ্লিকাগুলোর একটিকে স্বয়ংক্রিয়ভাবে নতুন প্রাইমারি হিসেবে প্রমোট (Promote) করা হয়।
Replication Lag চ্যালেঞ্জ

প্রাইমারি থেকে রেপ্লিকাতে ডাটা সিঙ্ক হতে ৫০-২০০ মিলিসেকেন্ড সময় লাগতে পারে। ইউজার প্রোফাইল আপডেট করে সাথে সাথে রিলোড দিলে যদি রেপ্লিকা থেকে ডাটা আসে, সে পুরানো ডাটা দেখতে পারে। সমাধান: ক্রুশিয়াল ডাটা (যেমন: পেমেন্ট বা প্রোফাইল সেভ করার ঠিক পরবর্তী রিড) সরাসরি প্রাইমারি ডাটাবেজ থেকে রিড করা।

৫. Data Sharding ও Hotspot সমস্যা

Horizontal Partitioning, Celebrity Problem & Salting Technique

Sharding কী?

যখন আপনার ডাটাবেজের সাইজ টেরাবাইট ছাড়িয়ে যায় এবং একটি একক মেশিনের হার্ডডিস্কে জায়গা হয় না, তখন সম্পূর্ণ টেবিলকে ছোট ছোট ভাগে ভেঙে একাধিক স্বাধীন ডাটাবেজ সার্ভারে ভাগ করে রাখাকে Sharding বা Horizontal Partitioning বলা হয়। প্রতিটি অংশকে বলা হয় Shard।

Shard Key সিলেকশন স্ট্র্যাটেজি

  • Range-Based Sharding: যেমন ইউজার আইডি ১-১০ লাখ Shard-1 এ, ১০-২০ লাখ Shard-2 এ। (ঝুঁকি: নতুন সব ইউজার শুধু শেষের শার্ডে হিট করে)।
  • Hash-Based Sharding: `hash(user_id) % num_shards` দিয়ে ডাটা সমানভাবে সব শার্ডে ছড়িয়ে দেওয়া হয়।
  • Geographic Sharding: দেশের ভিত্তিতে (যেমন: বাংলাদেশ ইউজাররা Dhaka Shard এ, আমেরিকানরা US Shard এ)।

The Hotspot (Celebrity) Problem 🔥

হটস্পট হলো এমন এক বিপজ্জনক অবস্থা যখন পুরো ক্লাস্টারের বাকি সার্ভারগুলো অলস বসে থাকে, অথচ মাত্র একটি নির্দিষ্ট শার্ডে অসম পরিমাণ ট্রাফিক পড়ে সার্ভারটি ৯৯% CPU তে পৌঁছে ক্র্যাশ করে!

সেলিব্রিটি সমস্যা (Twitter/Facebook/Instagram)

সাধারণ ইউজারের হয়তো ১০০ ফলোয়ার। কিন্তু ক্রিশ্চিয়ানো রোনালদো বা শাকিব আল হাসান যখন একটি পোস্ট করেন, সাথে সাথে কোটি কোটি ফ্যান সেই পোস্টে লাইক/কমেন্ট করতে একই শার্ডে হিট করে। ফলস্বরূপ রোনালদোর ডেটা যে শার্ডে সংরক্ষিত, সেই শার্ড পুরোপুরি ডাউন হয়ে যায়!

হটস্পট সমাধানের টেকনিকসমূহ

  1. Salting (সল্টিং): হট কি-এর সাথে র‍্যান্ডম প্রিফিক্স যোগ করা (যেমন: `ronaldo_post_101` এর বদলে `ronaldo_post_101_#1`, `ronaldo_post_101_#2` ... `_#10`)। ফলে রাইটগুলো ১০টি ভিন্ন ভিন্ন শার্ডে সমানভাবে বিভক্ত হয়ে যায়।
  2. Multi-Layer Redis Caching: ডাটাবেজে হিট যেতেই দেওয়া যাবে না; ফ্রন্টলাইনে Redis ক্লাস্টারে কন্টেন্ট ক্যাশ করে রাখা হবে।
  3. Prometheus ও Grafana অ্যালার্টিং: যদি কোনো একক শার্ডের ট্রাফিক ক্লাস্টারের গড়ের ৩ গুণ (3x) ছাড়িয়ে যায়, সাথে সাথে স্বয়ংক্রিয় অ্যালার্ট ফায়ার করা।

৬. Consistent Hashing ও Virtual Nodes

Solving the Modulo Remapping Catastrophe with Hash Rings

স্বাভাবিক Hashing এর মারাত্মক সমস্যা

সাধারণত সার্ভার নির্ধারণে ফর্মুলা ব্যবহার করা হয়: `server = hash(key) % N` (যেখানে N = সার্ভার সংখ্যা)। ধরুন আপনার ৪টি সার্ভার আছে। এখন ট্রাফিক বেড়ে যাওয়ায় আপনি ৫ নম্বর সার্ভার যোগ করলেন (N=5)। এখন শতকরা ৮০% থেকে ৯০% কি-এর ম্যাপিং পরিবর্তন হয়ে যাবে! ফলে ক্যাশ মিসের বন্যা বয়ে যাবে এবং ডাটাবেজ সাথে সাথে ক্র্যাশ করবে।

Consistent Hashing কীভাবে সমাধান করে?

কনসিস্টেন্ট হ্যাশিং-এ সার্ভার এবং ডেটা কি (Key) উভয়কেই একটি বৃত্তাকার Hash Ring (০° থেকে ৩৬০°)-এ ম্যাপ করা হয়।

  • Clockwise Routing: কোনো ডেটা কি রিং-এর যে পয়েন্টে পড়ে, সেখান থেকে ঘড়ির কাঁটার দিকে (Clockwise) ঘুরে প্রথম যে সার্ভার নোড পাওয়া যায়, ডাটাটি সেই সার্ভারে স্টোর হয়।
  • Minimal Remapping: নতুন একটি সার্ভার যোগ বা রিমুভ করলে পুরো ক্লাস্টারের সব কি পরিবর্তন হয় না; কেবলমাত্র নতুন সার্ভারটির পূর্ববর্তী অংশের কি-গুলো রি-ম্যাপ হয় (গড়ে মাত্র k/N সংখ্যক কি)।

ভার্চুয়াল নোডস (Virtual Nodes / V-Nodes) কেন লাগে?

যদি সার্ভার মাত্র ৩টি থাকে (A, B, C), তবে রিং-এ তারা অসমান দূরত্বে পড়তে পারে (যেমন: A দখল করলো ৮০% অংশ, B পেল ১০%)। এই সমস্যা সমাধান করতে প্রতিটি ফিজিক্যাল সার্ভারকে রিং-এ একাধিক ছদ্মবেশী ভার্চুয়াল নোড (যেমন: A1, A2, A3, B1, B2, B3) হিসেবে বসানো হয়। ফলে লোড সম্পূর্ণ নিখুঁতভাবে সবার মাঝে সমানভাবে বণ্টিত হয়।

৭. Microservices Architecture ও DDD বাউন্ডারি

Monolith vs Microservices, Domain Driven Design, API Gateway & Service Discovery

Microservices এর আসল সংজ্ঞা

একটি বিশাল অ্যাপ্লিকেশনকে একটিমাত্র কোডবেজে (Monolith) না রেখে ব্যবসায়িক সক্ষমতার (Business Capability) ভিত্তিতে কতগুলো স্বাধীন, ছোট এবং আলাদা আলাদাভাবে ডিপ্লয়যোগ্য সার্ভিসে ভাগ করার আর্কিটেকচারকেই Microservices বলে। প্রতিটি সার্ভিস তার নিজস্ব ডাটাবেজের মালিকানা নিজেই রাখে (Database per Service)।

কমন ভুল ধারণা (Common Pitfall)

মাইক্রোসার্ভিস মানেই প্রতি ফাইলে একটি সার্ভিস বা যত ছোট সম্ভব ভাগ করা নয়! ভুল বাউন্ডারি বানালে নেটওয়ার্ক ওভারহেড ও ডিস্ট্রিবিউটেড জটিলতায় পুরো কোম্পানি দেউলিয়া হতে পারে। বাউন্ডারি নির্ধারণ করতে হয় Domain-Driven Design (DDD)-এর Bounded Context অনুযায়ী (যেমন: Order Context, Payment Context, Inventory Context)।

কোর কম্পোনেন্টসমূহ

  • API Gateway: ক্লায়েন্ট সরাসরি ইন্টারনাল সার্ভিসে কল করে না। গেটওয়ে অথেন্টিকেশন (JWT), রেট লিমিটিং, SSL টার্মিনেশন এবং রিকোয়েস্ট রাউটিং হ্যান্ডেল করে।
  • Service Discovery: ক্লাউডে সার্ভারগুলোর IP প্রতিনিয়ত পরিবর্তন হয়। সার্ভিসের নাম ধরে IP খুঁজে বের করার জন্য Consul বা Kubernetes DNS ব্যবহৃত হয়।
  • Communication: সিঙ্ক্রোনাস হলে gRPC (উচ্চগতির বাইনারি RPC) বা REST; অ্যাসিনক্রোনাস হলে Kafka / RabbitMQ।

৮. Distributed Transactions ও Saga Pattern

Choreography vs Orchestration & Compensating Transactions

সমস্যা: ডিস্ট্রিবিউটেড পরিবেশে ACID ট্রানজ্যাকশন অসম্ভব

মনোলিথে একটি সাধারণ `BEGIN TRANSACTION ... COMMIT` দিয়ে অর্ডার তৈরি, টাকা কাটা এবং ইনভেন্টরি আপডেট নিশ্চিত করা যেত। কিন্তু মাইক্রোসার্ভিসে অর্ডার থাকে Order DB তে, টাকা থাকে Payment DB তে, আর স্টক থাকে Inventory DB তে। পেমেন্ট সাকসেসফুল কিন্তু ইনভেন্টরি ফেল করলে কী হবে?

Saga Pattern: ক্ষতিপূরণমূলক ট্রানজ্যাকশন (Compensating Actions)

সাগা প্যাটার্ন প্রতিটি লোকাল ট্রানজ্যাকশনের সাথে একটি করে Compensating Transaction (উল্টো অ্যাকশন) সংজ্ঞায়িত করে:

[ Step 1: Create Order ] ──▶ [ Step 2: Charge Payment ] ──▶ [ Step 3: Update Inventory ❌ FAIL ] │ [ Order CANCELLED ] ◀────── [ Refund Money ] ◀─────────────────────────┘

সাগা বাস্তবায়নের দুই স্টাইল

  • Choreography (কোরিওগ্রাফি): কোনো সেন্ট্রাল কন্ট্রোলার থাকে না। প্রতিটি সার্ভিস ইভেন্ট শুনে নিজেই পরবর্তী ডিসিশন নেয় (সহজ প্রজেক্টের জন্য উপযুক্ত)।
  • Orchestration (অর্কেস্ট্রেশন): একটি সেন্ট্রাল অর্কেস্ট্রেটর (যেমন: Temporal বা AWS Step Functions) পুরো ওয়ার্কফ্লো নিয়ন্ত্রণ করে (জটিল ফাইন্যান্সিয়াল সিস্টেমের জন্য প্রিফার্ড)।

৯. Resiliency ও Circuit Breaker Pattern

Fail Fast, Cascading Outage Prevention & Idempotency

Cascading Failure ও ক্যাসকেডিং আউটরেজ

যদি কোনো ডাউনস্ট্রিম সার্ভিস (যেমন: SMS Gateway) স্লো বা ক্র্যাশ হয়ে যায়, তবে আপস্ট্রিম সার্ভিসগুলো তাদের থ্রেড এবং মেমোরি আটকে রেখে অপেক্ষা করতে করতে নিজেরাও ক্র্যাশ করে। একে Cascading Failure বলে।

Circuit Breaker-এর ৩টি অবস্থা

  • CLOSED (স্বাভাবিক অবস্থা): সমস্ত ট্রাফিক নির্বিঘ্নে পাস হয়। ফেইলিওর রেট পর্যবেক্ষণ করা হয়।
  • OPEN (ট্রিপ্ড অবস্থা): পরপর কয়েকটি রিকোয়েস্ট ফেইল করলে সার্কিট "ওপেন" হয়ে যায়। পরবর্তী সমস্ত রিকোয়েস্ট সাথে সাথে ফেইল-ফাস্ট (Fast Fail / Fallback) করে ফিরিয়ে দেওয়া হয়, ডাউনস্ট্রিম সার্ভারে কোনো রিকোয়েস্ট পাঠানো হয় না।
  • HALF-OPEN (টেস্টিং অবস্থা): একটি নির্দিষ্ট বিরতির পর (যেমন: ৩০ সেকেন্ড) সার্কিট সামান্য কিছু টেস্ট রিকোয়েস্ট ডাউনস্ট্রিমে পাঠিয়ে দেখে সার্ভিসটি সুস্থ হয়েছে কিনা। যদি সুস্থ হয়, তবে CLOSED এ ফিরে যায়।
Idempotency (আইডেমপোটেন্সি) কেন জীবন রক্ষাকারী?

নেটওয়ার্ক ফেইল হলে ক্লায়েন্ট স্বয়ংক্রিয়ভাবে রিট্রাই করে। পেমেন্ট এপিআই যদি Idempotent না হয়, ইউজারের কার্ড থেকে ২ বার টাকা কেটে যাবে! রিকোয়েস্ট হেডারে ইউনিক Idempotency-Key: UUID পাঠিয়ে সার্ভারে চেক করতে হয় এই আইডি আগে প্রসেস হয়েছে কিনা।

১০. Message Queue ও অ্যাসিঙ্ক প্রসেসিং

Decoupling, Traffic Leveling, Dead Letter Queue (DLQ) & Kafka

মেসেজ কিউ এর মূলনীতি

Message Queue হলো Producer (যে কাজ তৈরি করে) এবং Consumer/Worker (যে কাজ সম্পাদন করে)-এর মাঝখানে থাকা একটি নির্ভরযোগ্য বাফার। ইউজারের রিকোয়েস্টে যেসব কাজ সঙ্গে সঙ্গে করার প্রয়োজন নেই (যেমন: ইমেইল পাঠানো, PDF জেনারেট করা, ভিডিও এনকোডিং) তা কিউ-তে রেখে দিয়ে ইউজারকে তাৎক্ষণিক রেসপন্স দেওয়া হয়।

রেস্তোরাঁর সহজ মানসিক মডেল (Mental Model)

আপনি যখন রেস্তোরাঁয় অর্ডার দেন, ওয়েটার (Producer) রান্নাঘরে গিয়ে রান্না শেষ না হওয়া পর্যন্ত দাঁড়িয়ে থাকে না। সে অর্ডারটি শেফের বোর্ডে (Queue) ক্লিপ করে রেখে আপনাকে টোকেন দিয়ে পরবর্তী কাস্টমারের কাছে চলে যায়। শেফ (Worker) ফ্রি হলে বোর্ড থেকে অর্ডার নিয়ে রান্না করে।

DLQ (Dead Letter Queue) কী?

যদি কোনো খারাপ মেসেজ (যেমন: করাপ্টেড ডাটা) ৩ বা ৫ বার রিট্রাই করার পরও প্রসেস হতে ব্যর্থ হয়, তবে সেই মেসেজটি মূল কিউ ব্লক না করে একটি আলাদা Dead Letter Queue (DLQ)-তে পাঠিয়ে দেওয়া হয়। পরবর্তীতে ইঞ্জিনিয়াররা লগ অ্যানালাইসিস করে বাগ ফিক্স করতে পারেন।

১১. Publisher-Subscriber (Pub/Sub) মডেল

Fan-Out Pattern, Kafka Consumer Groups & Partition Scaling

Queue বনাম Pub/Sub-এর পার্থক্য

প্যারামিটার Message Queue (Point-to-Point) Pub/Sub (Publisher-Subscriber)
মেসেজ প্রাপক একটি মেসেজ কেবল একজন ওয়ার্কার প্রসেস করবে এবং এরপর কিউ থেকে মুছে যাবে। একটি ইভেন্ট সাবস্ক্রাইব করা সমস্ত সার্ভিস (Multiple Subscribers) কপি পাবে (Fan-Out)।
ব্যবহারের ক্ষেত্র কাজের দায়িত্ব ভাগ করা (Job Processing, Background Task)। ইভেন্ট ব্রডকাস্টিং (Order Created ➔ Email + SMS + Analytics + Inventory)।

Kafka কীভাবে মিলিয়ন ইভেন্ট স্কেল করে?

অ্যাপাচি কাফকা (Apache Kafka) একটি টপিককে একাধিক Partition-এ ভাগ করে রাখে। প্রতিটি পার্টিশনে মেমোরির বদলে সিকোয়েনশিয়াল ডিস্কে লগ হিসেবে ডাটা লেখা হয়। একটি Consumer Group-এর ওয়ার্কাররা আলাদা আলাদা পার্টিশন প্যারালালি প্রসেস করে, যার মাধ্যমে সেকেন্ডে লাখ লাখ ইভেন্ট হ্যান্ডেল করা সম্ভব হয়।

১২. Distributed Caching আর্কিটেকচার

Cache-Aside, Stampede, Penetration, Avalanche & Eviction (LRU)

The Golden Rule of Caching

"Database is the single source of truth; cache is merely an acceleration layer."
র‍্যাম (RAM) ডিস্কের চেয়ে ১,০০০ গুণ দ্রুত। কিন্তু ক্যাশের মেমোরি সীমিত, তাই ক্যাশ ডিজাইন অত্যন্ত কৌশলগত হতে হয়।

বিপজ্জনক ৪টি ক্যাশ সমস্যা ও তাদের সমাধান

সমস্যা কেন ঘটে? প্রোডাকশন সমাধান
Cache Stampede একটি বহুল পঠিত কি এক্সপায়ার হওয়ার সাথে সাথে হাজার হাজার কনকারেন্ট রিকোয়েস্ট একইসাথে ডাটাবেজে হিট করে। Single-Flight / Mutex Lock: মাত্র একটি রিকোয়েস্ট লক নিয়ে ডাটাবেজে যাবে, বাকিরা অপেক্ষা করে ক্যাশ আপডেট হওয়ার পর ডাটা পাবে।
Cache Penetration হ্যাকার বা বাগি ক্লায়েন্ট এমন কি (যেমন `user/99999999`) দিয়ে রিকোয়েস্ট করে যা ডাটাবেজেও নেই। প্রতিবার ক্যাশ মিস হয়ে ডাটাবেজ চাপে পড়ে। Bloom Filter বা Negative Caching (নাল ভ্যালু ৬০ সেকেন্ডের জন্য ক্যাশে সেভ রাখা)।
Cache Avalanche ক্যাশের লাখ লাখ কি একই সময়ে (যেমন রাত ১২:০০ টায়) একসাথে এক্সপায়ার হয়ে যায়। TTL Jitter: ফিক্সড টাইমের বদলে কিছুটা র‍্যান্ডমনেস যোগ করা (`TTL = 300 + random(0, 60)` সেকেন্ড)।
Cache Eviction ক্যাশের মেমোরি ফুল হয়ে যাওয়া। LRU (Least Recently Used) বা LFU (Least Frequently Used) পলিসি।

১৩. Single Point of Failure (SPOF) নির্মূল

Redundancy, Multi-AZ, Multi-Region & Chaos Engineering

SPOF কী?

সিস্টেমের যেকোনো একটি একক কম্পোনেন্ট যার ব্যর্থতার কারণে সম্পূর্ণ সিস্টেম অচলাবস্থায় রূপ নেয়, তাকেই Single Point of Failure (SPOF) বলা হয়।

বাস্তব ট্র্যাজেডি: ফেসবুক ২০২১ এর ৬ ঘণ্টার গ্লোবাল ব্ল্যাকআউট

৪ অক্টোবর ২০২১ এ একটি ভুল BGP কনফিগারেশন আপডেটের কারণে ফেসবুকের নিজস্ব DNS সার্ভারগুলো ইন্টারনেট থেকে বিচ্ছিন্ন হয়ে যায়। সবচেয়ে ভয়াবহ ব্যাপার হলো, ফেসবুকের ইন্টারনাল অফিস নেটওয়ার্ক এবং ডিজিটাল দরজার চাবিও সেই একই নেটওয়ার্কের উপর নির্ভরশীল থাকায় ইঞ্জিনিয়াররা ফিজিক্যাল ডেটাসেন্টারে পর্যন্ত ঢুকতে পারছিলেন না!

The Nines of Availability (অ্যাভেইলেবিলিটি ম্যাথ)

ক্লাউড সার্ভিসের নির্ভরযোগ্যতা প্রকাশ করতে "Nines" পরিমাপ ব্যবহৃত হয়:

  • 99% (Two Nines): বছরে ৮৭.৬ ঘণ্টা ডাউনটাইম (ইন্টারনাল টুলের জন্য মানানসই)।
  • 99.9% (Three Nines): বছরে ৮.৭৬ ঘণ্টা ডাউনটাইম (স্ট্যান্ডার্ড SaaS)।
  • 99.99% (Four Nines): বছরে মাত্র ৫২.৬ মিনিট ডাউনটাইম (ব্যাংকিং ও ই-কমার্স)।
  • 99.999% (Five Nines): বছরে মাত্র ৫.২৬ মিনিট ডাউনটাইম (টেলিকম ও মিশন-ক্রিটিক্যাল হেলথকেয়ার)।

১৪. CDN ও এজ কম্পিউটিং আর্কিটেকচার

Edge PoPs, Anycast Routing, WAF & Cloudflare Optimization

CDN কীভাবে আলোর গতিতে কনটেন্ট পরিবেশন করে?

আপনার অরিজিন সার্ভার যদি আমেরিকায় থাকে, তবে বাংলাদেশ থেকে একটি রিকোয়েস্ট সমুদ্রের তলদেশের ফাইবার ক্যাবল দিয়ে যেতে-আসতে ন্যূনতম ২০০-২৫০ মিলিসেকেন্ড সময় নষ্ট হয়।

একটি CDN (Content Delivery Network) সারা পৃথিবীর শত শত শহরে Edge Server (PoP - Point of Presence) বসিয়ে রাখে। Anycast BGP Routing এর মাধ্যমে ঢাকার ইউজারের রিকোয়েস্ট স্বয়ংক্রিয়ভাবে নিকটস্থ সিঙ্গাপুর বা ঢাকা PoP-এ চলে যায়, যার লেটেন্সি মাত্র ১০-২০ মিলিসেকেন্ড!

এজ কম্পিউটিং (Edge Computing): শুধু ফাইল ক্যাশিং নয়

আধুনিক সিডিএন (যেমন: Cloudflare Workers, Vercel Edge) শুধুমাত্র ছবি বা সিএসএস ক্যাশ করে না, বরং ইউজারের একদম দরজার কাছে জাভাস্ক্রিপ্ট/WASM কোড এক্সিকিউট করে। ফলে অথেন্টিকেশন ভেরিফিকেশন, A/B টেস্টিং এবং রিডাইরেকশন অরিজিন সার্ভারকে স্পর্শ না করেই ১০ মিলিসেকেন্ডে সম্পন্ন হয়ে যায়।