System Design MCQ — সিস্টেম ডিজাইন প্রশ্নব্যাংক বাংলায় | পর্ব ৬৩

Q: Cache-aside-এ লেখার পরে key delete করা হলো, তবু কেন পুরোনো মান ফিরে আসে? কোন ক্রম সবচেয়ে নিরাপদ?

Cache-aside -এ cache নিজে database চেনে না; app miss পেলে database পড়ে মানটি cache-এ বসায় (set). ঝামেলা দুটি কাজের ফাঁকে। সময়রেখা: পাঠক A miss পেয়ে database থেকে v1 পড়লেন, কিন্তু set-এর আগে থেমে গেলেন (GC pause বা ধীর network). এর মধ্যে লেখক v2 commit করে key delete করলেন। তারপর A দেরিতে v1 set করলেন। এখন cache-এ পুরোনো v1, আর delete ইতিমধ্যে হয়ে গেছে — TTL শেষ না হওয়া পর্যন্ত সবাই v1 পাবেন। ক্রমের তুলনা: আগে cache delete, তারপর database update সবচেয়ে খারাপ — পুরো লেখার সময় জুড়ে যেকোনো পাঠক পুরোনো মান আবার বসাতে পারেন। Database update, তারপর cache-এ নতুন মান SET -এ দুই লেখকের ক্রম উল্টে গেলে পুরোনোটি শেষে বসে। প্রচলিত নিরাপদ পথ: commit, তারপর delete — জানালাটি সরু হয়, কিন্তু শূন্য নয়।

Q: Raft-এর majority আর lease-এর মেয়াদ — দুটি “নিরাপদ” হিসাব কোথায় ভুল গোনা হয়?

Majority গোনা। n টি node-এর Raft cluster-এ commit আর নির্বাচন দুটিতেই লাগে ⌊n ÷ ২⌋ + ১টি সম্মতি, আর leader নিজেও একটি। তাই ৫টি node সয় ২টি বিকলতা, ৬টিও ২টি — majority ৪ হয়ে যায়, সহনশীলতা বাড়ে না, উল্টো প্রতিটি commit-এ বেশি ack. সাধারণ সূত্র: f টি বিকলতা সইতে 2f + 1টি node. Latency-র দিকেও ফাঁদ: commit-এর সময় গড় RTT নয়, leader বাদে k-তম দ্রুততম follower-এর RTT — ৭টির cluster-এ তৃতীয় দ্রুততম। Lease-এর মেয়াদ দেখা। একটি client lock পেল ১৫ সেকেন্ডের lease-এ। লেখার ঠিক আগে নিজের ঘড়িতে দেখল “এখনো ৩ সেকেন্ড বাকি”, তারপর GC pause-এ ২০ সেকেন্ড থেমে রইল। এর মধ্যে মেয়াদ ফুরিয়েছে, lock service অন্য client-কে lock দিয়েছে। প্রথমজন জেগে উঠে পুরোনো বিশ্বাসে লিখল — দুজন মালিক, ডেটা নষ্ট। মেয়াদ দেখা আর লেখার মাঝে যেকোনো থামা এই ফাঁক খোলে, আর কোনো client-ই নিজের থামা টের পায় না। প্রতিকার fencing token : প্রতিবার lock দেওয়ার সময় বাড়তে থাকা একটি সংখ্যা (৩৩, তারপর ৩৪)।

এক নজরে · এই পাতা কীভাবে ব্যবহার করবেন

২০৮টি প্রশ্ন, কোর্সের ক্রমে: প্রথমে কৌশল, তারপর মডিউল ১ থেকে ৯ — প্রতিটি অংশের শুরুতে “যে পর্বগুলো ঝালিয়ে নেবেন” তালিকা।
আগে খাতায় উত্তর, তারপর চাপুন: যে অপশনই চাপুন, ব্যাখ্যা খুলবে — কেন সঠিক বা ভুল, আর কোন পর্বে বিষয়টি আছে।
কঠিনতা প্রশ্নের শুরুতেই: (সহজ), (মাঝারি) বা (কঠিন); মেশানো আছে সংজ্ঞা, নকশা বাছাই, আচরণ অনুমান, numerical আর case study.
Numerical script দিয়ে যাচাই করা: রীতি (যেমন ১ দিন = 86,400 s) প্রশ্নেই লেখা। তিনটি ছোট JavaScript checker-এ সংখ্যা বদলে নিজের হিসাবও মেলাতে পারবেন।
স্কোর দেখে দুর্বল মডিউল খুঁজুন: নিচে প্রথম চেষ্টার স্কোর দেখাবে; বেশি ভুলের অংশের পর্বগুলো আবার পড়ুন।

এই পর্বে যা করবেন

System design-এর MCQ কোন কোন ছাঁচে আসে তা চেনা, আর বাদ দেওয়ার পদ্ধতি ও সময় ভাগ শেখা
দিনের সেকেন্ড, bit বনাম byte, percentile, availability-র গুণফল, quorum আর majority — রীতি ও একক দিয়ে ভুল অপশন কেটে দেওয়া
CAP-এর ভুল ব্যাখ্যা, quorum বনাম linearizability, at-least-once আর idempotency, cache-aside-এর পুরোনো মান — বড় ভুল ধারণাগুলো দূর করা
পুরো কোর্সের ২০৮টি প্রশ্নে নিজের দুর্বল মডিউল খুঁজে সেই পর্বে ফিরে যাওয়া
AI দিয়ে আরও MCQ বানানো, আর তার “সঠিক উত্তর” হিসাব করে ও পর্বের সাথে মিলিয়ে যাচাই করা

১ · MCQ কীভাবে সামলাবেন — প্রশ্নের ধরন, বাদ দেওয়া, রীতি আর সময় ভাগ

ধরুন খুলনার সাদিয়া একটি backend পদের অনলাইন screening-এ চল্লিশটি MCQ পেলেন। প্রশ্ন চেনা — “R + W > N হলে কী নিশ্চিত হয়?”, “৯৯.৯৫% মানে মাসে কত downtime?” — কিন্তু অপশনে “linearizable” আর “শুধু overlap” পাশাপাশি, “21.6 মিনিট” আর “43.2 মিনিট” দুটিই। পরে দেখলেন, বেশিরভাগ ভুল এসেছে একটি রীতি, একটি একক বা “ভুল” শব্দটি চোখ এড়িয়ে যাওয়ায়।

প্রশ্নকর্তা জেনেশুনে এমন ভুল অপশন রাখেন, যা কোনো আধা-সত্য নিয়ম বা চেনা হিসাবের ভুল থেকে আসে — একে বলে distractor. এই কোর্সের distractor-গুলো ঘুরেফিরে বারোটি ভুল ধারণা থেকেই আসে (নিচের টেবিল); সেগুলো চিনলে অর্ধেক কাজ শেষ।

প্রশ্নের ছয় ছাঁচ

ধরন	উদাহরণ	কৌশল
সংজ্ঞা ও জোড়া-ধারণা	RPO বনাম RTO, event বনাম command	সংজ্ঞার একটি শব্দ ধরে পার্থক্য করুন (ডেটা বনাম সময়, ঘটে-যাওয়া বনাম করার আদেশ)
“কোন নকশা মানায়”	তারকা আর সাধারণের feed, ফ্ল্যাশ সেলের মজুত	আগে requirement-এর কঠিন শর্তটি খুঁজুন — consistency, latency না খরচ
আচরণ অনুমান	Commit-এর আগে crash হলে consumer কোথা থেকে শুরু করে	সময়রেখা আঁকুন: কোন ঘটনা কোন ঘটনার আগে
ছোট numerical	QPS, availability, quorum, Bloom filter-এর আকার	রীতি আর একক আগে খাতায়, উত্তরের মাত্রা আগে আন্দাজ
“কোনটি ভুল”	Consistent hashing নিয়ে কোন দাবিটি ভুল	প্রতিটি অপশনের পাশে স বা ভু লিখুন; “ভুল” শব্দে দাগ দিন
Case study	URL shortener-এর code-দৈর্ঘ্য, chat-এর ক্রম	পর্ব ৫৪–৬১-এর সিদ্ধান্তগুলো কোন requirement থেকে এসেছিল, মনে করুন

প্রশ্নগুলো নকশার কোন অংশে

কোনো প্রশ্নে আটকালে আগে ঠিক করুন সেটি নিচের ছবির কোন বাক্সের — তাতেই কোন নিয়ম খাটবে, অনেকটা বোঝা যায়।

একটি অনুরোধের পথ — কোন অংশ কোন মডিউলে

Client, DNS আর CDN, gateway, load balancer, stateless service, cache, queue, database; নিচে distributed তত্ত্বের স্তর

কৌশল ১ · বাদ দেওয়ার পদ্ধতি — একটি কঠিন scenario ধাপে ধাপে

সঠিক উত্তর সরাসরি খোঁজার চেয়ে ভুলগুলো বাদ দেওয়া প্রায়ই সহজ — একে বলে elimination method. প্রতিটি অপশনের পেছনের নিয়মটি খুঁজে সেই নিয়ম দিয়েই কেটে দিন। নিচের প্রশ্নের তিনটি ভুল অপশন তিনটি বড় ভুল ধারণা থেকে বানানো।

শর্ত খোঁজাbalance ≥ 0আর partition
“CA” নেইP ঘটেখ বাদ
দুই পাশে লেখাLWWক বাদ
Quorum ≠linearizableগ বাদ
উত্তরঘ · CPদাম জেনে

প্রশ্ন (কঠিন)mobile banking · কাল্পনিক

নিয়ম: ব্যালান্স কখনো ঋণাত্মক নয়।
দুই ডেটা সেন্টারের মাঝে partition.
টাকা তোলায় কোন নকশা ঠিক?

ক) দুই পাশেই তোলা, পরে LWW
খ) “CA” — partition ধরা হবে না
গ) N=3, W=2, R=2, sloppy quorum
ঘ) অ্যাকাউন্টপ্রতি consensus;
   সংখ্যালঘু পাশে তোলা বন্ধ

ধাপ ২partition বাছাই নয়

Partition ঘটবেই — প্রশ্ন শুধু
তখন C না A.

দুই পাশে চালিয়ে যাওয়া মানে
আসলে A বেছে নেওয়া; “CA” নামে
কোনো তৃতীয় পথ নেই।

খ) “CA”

ধাপ ৩শর্ত ভাঙে কি?

ব্যালান্স ১,০০০ টাকা।
বাম পাশে তোলা ৮০০ → দেখায় ২০০
ডান পাশে তোলা ৮০০ → দেখায় ২০০
আসল হিসাব: ১,০০০ − ১,৬০০ = −৬০০

LWW একটি তোলা নিঃশব্দে মোছে,
টাকা কিন্তু দুবারই বেরিয়েছে।

ক) দুই পাশে, পরে LWW

ধাপ ৪overlap ≠ শর্তযুক্ত লেখা

R + W = 4 > 3 — overlap আছে,
কিন্তু:
• sloppy quorum-এ বাইরের node-এর
  ack-ও গোনা হয়, overlap ভাঙে
• “ব্যালান্স ≥ টাকা হলে তবেই লেখা”
  একটি compare-and-set — তার
  জন্য consensus লাগে

গ) quorum + sloppy

ধাপ ৫উত্তর আর তার দাম

উত্তর: ঘ)
Majority পাশ (যেমন ৩টির ২টি)
লেখা চালায়; সংখ্যালঘু পাশে
তোলা “পরে চেষ্টা করুন”।

দাম: partition-এ কিছু ব্যবহারকারীর
availability যায় — PACELC-এ PC/EC.

আগে কঠিন শর্তটি খুঁজুন। দুটি চাবি-শব্দ: একটি invariant (ব্যালান্স ঋণাত্মক নয়) আর একটি ব্যর্থতা (network partition). এ দুটি না ধরে পড়লে সব অপশনই যুক্তিসংগত মনে হয় (পর্ব ২, ৪০)।
“CA” — CAP-এর সবচেয়ে প্রচলিত ভুল ব্যাখ্যা। Partition নকশাকারের বাছাই নয়; ভাঙনের সময় দুই পাশে কাজ চালালে আসলে availability বেছে নেওয়া হলো। খ বাদ (পর্ব ৪০)।
দুই পাশে লেখা নিলে শর্ত ভাঙে কি না, ছোট সংখ্যায় দেখুন। ১,০০০ টাকা থেকে দুই পাশে ৮০০ করে তোলা — প্রতিটি পাশ নিজের চোখে বৈধ, মিলিয়ে −৬০০. Last-write-wins একটি লেখা মোছে, বেরিয়ে যাওয়া টাকা ফেরায় না। ক বাদ (পর্ব ৪৬)।
Quorum-এর overlap আর linearizability এক নয়। R + W > N শুধু সম্পন্ন লেখার সাথে overlap দেয়; sloppy quorum তাও ভাঙে, আর শর্তযুক্ত লেখায় consensus লাগে। গ বাদ (পর্ব ৪১)।
উত্তর ঘ — দাম জেনেই বাছুন। প্রতিটি অ্যাকাউন্টের লেখা Raft-ধাঁচের majority-তে; সংখ্যালঘু পাশের ব্যবহারকারী সাময়িক তুলতে পারেন না। এই দামটি এক লাইনে বলতে পারাই আসল বোঝা (পর্ব ৪২, ৬০)।

কৌশল ২ · রীতি আর একক আগে, হিসাব পরে

Numerical-এ নম্বর বেশি হারায় গুণ-ভাগে নয়, রীতি আর এককে — দুই রীতির দুটি উত্তরই প্রায়ই অপশনে থাকে। এই পাতা কোর্সের পর্বগুলোর রীতি মানে; ভিন্ন হলে প্রশ্নেই লেখা।

বিষয়	রীতি বা সূত্র	যাচাইয়ের কৌশল
সময় আর হার	১ দিন = 86,400 s (প্রশ্নে বললে ≈ 10⁵); peak = গড় × প্রশ্নে দেওয়া গুণক	দুই রীতির উত্তরে প্রায় ১৬% তফাত — দুটিই অপশনে থাকতে পারে
Bit আর byte	1 byte = 8 bit; network-এর হার bit/s-এ, disk-এর byte/s-এ	MB/s থেকে Mbit/s-এ গেলে ৮ দিয়ে গুণ
Percentile	Nearest-rank: n টি মানের p-তম = ⌈p × n⌉-তম; fan-out-এ ধীর হওয়া 1 − (1 − p)^N	N × p নয় — সেটি ১০০%-ও ছাড়াতে পারে
Little আর queue	L = λ × W; M/M/1-এ W = S ÷ (1 − ρ)	ms-কে s-এ বদলে নিন; ρ → 1 হলে W বিস্ফোরিত
Availability	Series গুণফল; parallel 1 − Π(1 − a); A = MTBF ÷ (MTBF + MTTR), MTTR-এ টের পাওয়ার সময়ও	Series-এর ফল দুর্বলতম অংশেরও নিচে
Quorum আর Raft	R + W > N; লেখা সয় N − W, পড়া N − R বিকলতা; Raft majority ⌊n ÷ 2⌋ + 1	Leader নিজেও ভোট গোনে; জোড় n-এ সহনশীলতা বাড়ে না
SLO	Error budget = (1 − SLO) × জানালা; burn rate = error ratio ÷ (1 − SLO)	Budget মিনিটে, burn একটি গুণক
Key সরানো	hash mod N, N → N + 1: প্রায় N ÷ (N + 1) সরে; ring-এ প্রায় 1 ÷ (N + 1)	উত্তর ৯০% আর ১০% — দুটিই অপশনে থাকে

নিচের checker মডিউল ১, ৩ আর ৫-এর কয়েকটি numerical আবার করে; সংখ্যা বদলে নিজের প্রশ্নও মেলাতে পারেন:

// Re-check the most common system-design MCQ numericals before trusting an answer key.
const pct = (x, d = 2) => (100 * x).toFixed(d) + "%";
const mm1 = (S, rho) => S / (1 - rho);            // M/M/1 mean response time
const p = 0.99;                                    // one server's availability
console.log("QPS: 4.32e7 per day / 86,400 s :", 4.32e7 / 86400);
console.log("250 MB/s in Gbit/s             :", 250 * 8 / 1000);
console.log("Photos 2e6 x 500 KB x 365 x 3  :", (2e6 * 500e3 * 365 * 3 / 1e15).toFixed(3), "PB");
console.log("Servers 12000 / (800 x 0.75)   :", Math.ceil(12000 / (800 * 0.75)));
console.log("Fan-out 50, each 1% slow       :", pct(1 - 0.99 ** 50, 1));
console.log("Little: 2500/s x 80 ms         :", 2500 * 0.08, "in flight");
console.log("M/M/1 S = 5 ms, rho 0.6 -> 0.9 :", mm1(5, 0.6).toFixed(1), "->", mm1(5, 0.9).toFixed(1), "ms");
console.log("Downtime at 99.95%, 30 days    :", (30 * 24 * 60 * 0.0005).toFixed(1), "min");
console.log("Series 99.99 x 99.95 x 99.9    :", pct(0.9999 * 0.9995 * 0.999));
console.log("2 of 3 servers, 99% each       :", pct(p ** 3 + 3 * p * p * (1 - p)));
console.log("hash mod N, 9 -> 10 servers    :", pct(9 / 10, 0), "of keys move");
console.log("Ring, 19 -> 20 servers         :", pct(1 / 20, 0), "of keys move");
console.log("vnodes for sd/mean = 5%        :", Math.round((1 / 0.05) ** 2));
console.log("Hit ratio 99% -> 95%, DB load x:", ((1 - 0.95) / (1 - 0.99)).toFixed(1));
console.log("Read 2 ms + 20% x 30 ms        :", 2 + 0.2 * 30, "ms");

আউটপুট (নির্ধারিত, প্রতিবার একই):

QPS: 4.32e7 per day / 86,400 s : 500
250 MB/s in Gbit/s             : 2
Photos 2e6 x 500 KB x 365 x 3  : 1.095 PB
Servers 12000 / (800 x 0.75)   : 20
Fan-out 50, each 1% slow       : 39.5%
Little: 2500/s x 80 ms         : 200 in flight
M/M/1 S = 5 ms, rho 0.6 -> 0.9 : 12.5 -> 50.0 ms
Downtime at 99.95%, 30 days    : 21.6 min
Series 99.99 x 99.95 x 99.9    : 99.84%
2 of 3 servers, 99% each       : 99.97%
hash mod N, 9 -> 10 servers    : 90% of keys move
Ring, 19 -> 20 servers         : 5% of keys move
vnodes for sd/mean = 5%        : 400
Hit ratio 99% -> 95%, DB load x: 5.0
Read 2 ms + 20% x 30 ms        : 8 ms

প্রথম চার লাইন মডিউল ১-এর estimation; তারপর tail latency-র fan-out (৩৯.৫%), Little-এর সূত্র, M/M/1-এ ব্যস্ততা ৬০% থেকে ৯০% হলে latency চার গুণ, আর availability-র তিন হিসাব। শেষে key সরানোর দুই রীতি (৯০% বনাম ৫%), virtual node, আর hit ratio সামান্য কমায় database-এ পাঁচ গুণ চাপ। প্রতিটি সংখ্যা নিচের কোনো প্রশ্নের উত্তর।

কৌশল ৩ · সীমা দিয়ে আগেই বাদ

একটি সীমা জানলেই অনেক অপশন হিসাব ছাড়াই কাটে: series-এর availability দুর্বলতম অংশের বেশি নয়; fan-out-এ ধীর হওয়ার সম্ভাবনা ১০০%-এর কম কিন্তু একটি অংশের চেয়ে বেশি; Raft অর্ধেকের বেশি বিকলতা সয় না; cache-এর গড় latency hit আর miss-এর মাঝে।

কৌশল ৪ · negative marking আর সময় ভাগ

ভুলে নম্বর কাটলে (negative marking) আন্দাজ একটি হিসাবের সিদ্ধান্ত। ধরা যাক ঠিক হলে +১, ভুলে −০.২৫. চারটি অপশনে অন্ধ আন্দাজের গড় লাভ মাত্র +০.০৬২৫; একটি নিশ্চিতভাবে বাদ দিলে +০.১৬৭; দুটি বাদ দিলে +০.৩৭৫. সাধারণ নিয়ম: k টি অপশন বাকি থাকলে আন্দাজ লাভজনক, যতক্ষণ কাটা নম্বর ১ ÷ (k − ১)-এর কম। কত কাটে বা আদৌ কাটে কি না, পরীক্ষাভেদে আলাদা — নিজের পরীক্ষার নিয়ম দেখে নিন।

সময় ভাগ করুন দুই দফায়: প্রথমে সংজ্ঞার প্রশ্ন, numerical-এ চিহ্ন দিয়ে এগিয়ে যান; পরে চিহ্নিতগুলো, খাতায় — quorum-এ আগে N, W, R, scenario-তে আগে সময়রেখা।

বারোটি বড় ফাঁদ

প্রতিটি সারি একাধিক প্রশ্নে distractor হয়ে ফিরবে; শেষে মিলিয়ে দেখুন আপনার ভুলগুলো কোন সারিতে পড়ল।

ফাঁদ	ভুল ধারণা	সঠিক কথা
দুই “C”	“CAP-এর C আর ACID-এর C একই”	CAP-এর C = linearizability; ACID-এর C = অ্যাপের নিয়ম রক্ষা (পর্ব ২৪, ৪০)
“CA” সিস্টেম	“তিনটির যেকোনো দুটি বেছে নিন”	Partition ঘটেই; বাছাই শুধু তখন C না A, আর স্বাভাবিক সময়ে latency না consistency (পর্ব ৪০)
Quorum	“R + W > N মানে linearizable”	শুধু সম্পন্ন লেখার সাথে overlap; চলমান লেখা, LWW, sloppy quorum-এ ভাঙে (পর্ব ৪১)
Exactly-once	“broker exactly-once দিলে duplicate নেই”	At-least-once + idempotent consumer; চিহ্ন আর effect একই transaction-এ (পর্ব ৩৪)
Cache-aside	“লেখার পরে delete করলেই পুরোনো মান আর নয়”	দেরিতে আসা set পুরোনো মান বসাতে পারে; TTL-ই শেষ সীমা (পর্ব ২৮, ২৯)
গড় latency	“গড় ভালো, তাই অভিজ্ঞতাও ভালো”	p99 দেখুন; percentile-এর গড় নেওয়া যায় না (পর্ব ৪, ৫০)
Series availability	“মোট = দুর্বলতম অংশের সমান”	গুণফল — দুর্বলতম অংশেরও নিচে (পর্ব ৫, ৪৭)
Retry	“retry সবসময় নিরাপদ”	স্তরে স্তরে গুণ হয়; jitter, retry budget আর idempotency key লাগে (পর্ব ১৮, ৪৮)
Read replica	“replica দিলে লেখাও বাড়ে”	প্রতিটি follower সব লেখা প্রয়োগ করে; replica শুধু পড়া বাড়ায় (পর্ব ২২)
Snapshot isolation	“snapshot = serializable”	Lost update ঠেকায়, কিন্তু write skew ঘটতে দেয় (পর্ব ২৪)
Lease	“মেয়াদ দেখে লিখলেই নিরাপদ”	GC বা VM pause-এ দুজন মালিক; storage-কে fencing token যাচাই করতে হয় (পর্ব ৪৩)
Bloom filter	“‘আছে’ বললে নিশ্চিত আছে”	False positive হয়, false negative হয় না — “নেই” মানেই নেই (পর্ব ৪৫)

এই পাতার প্রশ্নগুলো সম্পর্কে: প্রশ্নগুলো এই কোর্সের জন্য নতুন করে লেখা — বিশ্ববিদ্যালয়ের পরীক্ষা, চাকরির লিখিত পরীক্ষা আর ইন্টারভিউতে এ ধরনের প্রশ্ন প্রায়ই আসে, এমন ধারণা থেকে বানানো; কোনোটিই কোনো নির্দিষ্ট পরীক্ষা বা প্রতিষ্ঠানের আসল প্রশ্ন নয়। Case study-গুলো কাল্পনিক সেবার, আর product-এর setting “লেখার সময়ে” ধরে বলা। প্রতিটি numerical ছোট প্রোগ্রামে মিলিয়ে দেখা। বড়, বহু-ধাপের estimation পাবেন পর্ব ৬২-এ, আর কারণসহ লিখিত উত্তর পর্ব ৬৪-এ।

২ · মডিউল ১ — System Design-এর ভিত্তি (২২টি প্রশ্ন)

এই অংশ পুরো কোর্সের ভিত্তি যাচাই করে: functional আর non-functional requirement, খামের পেছনের হিসাব, percentile আর Little-এর সূত্র, nines আর series-parallel availability, আর আট ধাপের নকশা-কাঠামো। সবচেয়ে বেশি নম্বর হারায় তিন জায়গায় — bit আর byte গুলিয়ে ফেলা (৮ গুণ ভুল), গড় latency দেখে p99 ভুলে যাওয়া, আর series-এ অংশ জুড়লে availability কমে যায়, এ কথা ভুলে যাওয়া।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ০১–০৬

পর্ব ০১ · System design কী আর পর্ব ০২ · Requirement আর trade-off — HLD বনাম LLD, একটি অ্যাপের ধাপে ধাপে বেড়ে ওঠা, FR বনাম NFR, push বনাম pull
পর্ব ০৩ · Back-of-the-envelope হিসাব — ১ দিন = ৮৬,৪০০ সেকেন্ড (≈ ১০^৫), KB বনাম KiB, bit বনাম byte, latency-র মই, সার্ভারের সংখ্যা
পর্ব ০৪ · Latency, throughput আর percentile — nearest-rank, fan-out-এ 1 − (1 − p)^N, L = λW, M/M/1-এ W = S/(1 − ρ)
পর্ব ০৫ · Availability আর reliability — nines-এর downtime, MTBF-MTTR-MTTD, series, parallel আর k-of-n
পর্ব ০৬ · একটি নকশা কীভাবে এগোয় — আট ধাপ, সময় ভাগ, জানা ভিড়ে cache warming

(সহজ) নিচের কোন সিদ্ধান্তটি high-level design (HLD)-এর, low-level design-এর নয়?

কোন সার্ভিস কোন database-এ লিখবে, মাঝে queue থাকবে কি না
FareCalculator class-এ কোন কোন method থাকবে
ভাড়ার নিয়মে Strategy pattern লাগবে কি না
চলকের নাম আর কোড লেখার রীতি কী হবে

(মাঝারি) একমাত্র app সার্ভারের CPU 90%, database-এর CPU 20%, আর session থাকে সার্ভারের memory-তে। আরও app সার্ভার যোগের আগে প্রথম কাজ?

Session shared store-এ সরিয়ে app-কে stateless করা
Database-কে কয়েকটি shard-এ ভাগ করা
Database-এর read replica যোগ করা
ছবি আর CSS-এর জন্য CDN বসানো

(মাঝারি) Peak-এ 20,000 read/s. Cache hit ratio 99% থেকে 95%-এ নামলে database-এ পৌঁছানো read কত গুণ হয়?

প্রায় ৪% বাড়ে
৪ গুণ
প্রায় অপরিবর্তিত
৫ গুণ

(সহজ) একটি ছবি শেয়ারের অ্যাপের জন্য নিচের কোনটি functional requirement?

Feed লোডের ৯৯% অনুরোধ ৩০০ ms-এর মধ্যে শেষ হবে
মাসে ৯৯.৯% সময় সেবা চালু থাকবে
ব্যবহারকারী ছবি আপলোড করে বন্ধুদের সাথে শেয়ার করতে পারবেন
সব ছবির একটি কপি অন্য region-এ থাকবে

(মাঝারি) একটি online দোকানের কোন ডেটার জন্য strong consistency সবচেয়ে জরুরি?

পণ্যের পাতায় দেখানো review-এর সংখ্যা
শেষ পিসটির stock কমানো আর অর্ডার নিশ্চিত করা
“যাঁরা এটি কিনেছেন, তাঁরা আরও কিনেছেন” সুপারিশ
পণ্যের ছবির thumbnail

(কঠিন) একটি feed-এ বেশিরভাগের কয়েকশো follower, অল্প কয়েকজনের কোটির বেশি। কোন নকশা মানানসই?

সবার জন্য fan-out on write (push)
সবার জন্য fan-out on read (pull)
সাধারণদের পোস্ট push, তারকাদের পোস্ট পড়ার সময় pull করে মেশানো (hybrid)
প্রতি মিনিটে সবার feed নতুন করে বানানো একটি batch job

(সহজ) দিনে 4.32 × 10⁷ অনুরোধ, সারা দিন সমানভাবে। ১ দিন = 86,400 s ধরলে গড় QPS কত?

432
12,000
5,000
500

(মাঝারি) Peak-এ বাইরে যায় 250 MB/s, সার্ভারের network লিংক 1 Gbit/s. লিংকটি কি যথেষ্ট?

হ্যাঁ — 250 MB/s লিংকের চার ভাগের এক ভাগ
হ্যাঁ — লিংকের প্রায় অর্ধেক ব্যবহার হবে
না — চাহিদা লিংকের প্রায় ২৫০ গুণ
না — 250 MB/s = 2 Gbit/s, লিংকের দ্বিগুণ

(মাঝারি) দিনে 2 × 10⁶ নতুন ছবি, প্রতিটি 500 KB (1 KB = 1,000 B), রাখতে হবে 365 দিন, replication factor 3. Index বাদে মোট storage?

প্রায় 1.1 PB
প্রায় 365 TB
প্রায় 1.1 TB
প্রায় 3.3 PB

(কঠিন) Peak 12,000 QPS; load test-এ একটি সার্ভার 800 QPS পারে; লক্ষ্য utilization 75%. Spare বাদে কমপক্ষে কতটি সার্ভার?

(মাঝারি) Latency-র মোটামুটি মাত্রায় কোন জোড়ার প্রথমটি দ্বিতীয়টির চেয়ে প্রায় ১,০০০ গুণ দ্রুত?

CPU-র L1 cache থেকে পড়া বনাম RAM থেকে পড়া
RAM থেকে পড়া বনাম SSD-র একটি random read
SSD-র random read বনাম hard disk-এর একটি seek
RAM থেকে পড়া বনাম hard disk-এর একটি seek

(সহজ) গড় latency 40 ms, কিন্তু p99 1.2 s. কোন কথাটি ঠিক?

মোটামুটি প্রতি ১০০টিতে ১টি অনুরোধ 1.2 s বা বেশি নেয়
99% অনুরোধ 40 ms-এর মধ্যে শেষ হয়
গড় ভালো, তাই অভিজ্ঞতাও ভালো
সবচেয়ে ধীর অনুরোধটি ঠিক 1.2 s নিয়েছে

(মাঝারি) ৫০টি latency মাপ ছোট থেকে বড় ক্রমে সাজানো। Nearest-rank পদ্ধতিতে p90 কোনটি?

৪৪তম মান
৪৫তম মান
৪৬তম মান
৪৫তম আর ৪৬তম মানের গড়

(কঠিন) একটি অনুরোধ ৫০টি backend-এ যায়, সবার উত্তরের অপেক্ষা করে; প্রতিটি স্বাধীনভাবে 1% সময় ধীর। অন্তত একটি ধীর উত্তরে আটকানোর সম্ভাবনা?

1%
প্রায় 39.5%
50%
প্রায় 60.5%

(মাঝারি) গড়ে 2,500 req/s আসে, প্রতিটি গড়ে 80 ms ভেতরে থাকে। Little-এর সূত্রে একসাথে গড়ে কতগুলো অনুরোধ চলছে?

200
31
200,000
20

(কঠিন) M/M/1-এ গড় service time 5 ms. Utilization 60% থেকে 90% হলে গড় response time কত গুণ হয়?

১.৫ গুণ
৪ গুণ
১০ গুণ
২ গুণ

(সহজ) 99.95% availability-র মাসিক (৩০ দিন) লক্ষ্যে মাসে সর্বোচ্চ কত downtime চলে?

৪৩ মিনিট ১২ সেকেন্ড
২১ মিনিট ৩৬ সেকেন্ড
৪ ঘণ্টা ২২ মিনিট ৪৮ সেকেন্ড
২ মিনিট ১০ সেকেন্ড

(মাঝারি) Series-এ তিনটি অংশ: load balancer 99.99%, app স্তর 99.95%, database 99.9%; ব্যর্থতা স্বাধীন। মোট availability?

99.9% — দুর্বলতম অংশের সমান
প্রায় 99.95% — তিনটির গড়
99.99%-এর বেশি — অংশ বাড়লে নির্ভরতা বাড়ে
প্রায় 99.84%

(কঠিন) Peak-এ অন্তত ২টি app সার্ভার লাগে, আছে ৩টি (N+1); প্রতিটি 99% available, ব্যর্থতা স্বাধীন। স্তরের availability?

প্রায় 99.9999%
প্রায় 97.03%
প্রায় 99.97%
99% — প্রতিটি সার্ভারের সমান

(মাঝারি) MTBF 998 ঘণ্টা; ব্যর্থতা টের পেতে গড়ে 30 মিনিট (MTTD), তারপর সারাতে আরও 90 মিনিট। Availability কত?

99.85%
99.6%
99.8%
99.98%

(সহজ) আট ধাপের নকশা-কাঠামোয় “হিসাব” (estimation)-এর ঠিক পরের ধাপ কোনটি?

High-level design-এর ছবি আঁকা
Deep dive
Failure mode-এর তালিকা
API — বাইরের দুনিয়া কীভাবে কথা বলবে

(মাঝারি) ফল প্রকাশের সাইটে ভিড়ের সময় আগেই জানা — প্রকাশের মুহূর্তে লাখো অনুরোধ। সবচেয়ে কার্যকর প্রস্তুতি?

ভিড়ের আগেই cache ভরে রাখা (cache warming)
Cache-এর TTL ছোট করা
CPU দেখে বাড়ে এমন autoscaling-এর ওপর ভরসা
Database-এ আরও কয়েকটি index যোগ করা

৩ · মডিউল ২ — যোগাযোগ আর API (১৮টি প্রশ্ন)

সার্ভারের দরজা আর তার ভাষা: RTT, DNS-এর TTL, safe ও idempotent method, status code, pagination, gRPC, WebSocket, API gateway আর schema-র সামঞ্জস্য। প্রচলিত ভুল: 401 আর 403 গুলিয়ে ফেলা, অসীম feed-এ offset, আর backward ও forward compatibility উল্টে বলা।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ০৭–১২

পর্ব ০৭ · System design-এর জন্য networking — TCP, TLS 1.2/1.3 আর QUIC-এর handshake, TTL আর failover, আলোর গতির সীমা, UDP কখন
পর্ব ০৮ · REST API নকশা — safe ও idempotent method, status code, cursor pagination, idempotency key, ETag
পর্ব ০৯ · gRPC আর GraphQL — চার ধরনের call, deadline, N+1 আর DataLoader
পর্ব ১০ · Real-time যোগাযোগ — polling-এর খরচ N/I আর দেরি I/২, SSE বনাম WebSocket, pub/sub backplane
পর্ব ১১ · Reverse proxy, API gateway আর BFF — proxy-র কাজ, X-Forwarded-For, gateway বনাম সার্ভিসের দায়িত্ব
পর্ব ১২ · Data format আর serialization — UTF-8-এর byte, Protobuf-এর field number, backward বনাম forward

(মাঝারি) RTT 80 ms, DNS আগেই cache-এ, সার্ভারের কাজের সময় নগণ্য। TCP + পূর্ণ TLS 1.2-এর নতুন connection-এ প্রথম byte আসতে মোটামুটি কত সময়?

240 ms
160 ms
320 ms
80 ms

(সহজ) একটি record-এর TTL 3,600 s রেখেই সার্ভারের IP বদলানো হলো। কোন কথাটি ঠিক?

সব ব্যবহারকারী সাথে সাথে নতুন IP পাবেন
কিছু resolver প্রায় এক ঘণ্টা পুরোনো IP দিতে পারে, তাই বদলের আগেই TTL কমানো উচিত
TTL শুধু ব্রাউজারের cache-এর জন্য, resolver মানে না
খোলা TCP connection-গুলোও সাথে সাথে নতুন IP-তে সরে যায়

(মাঝারি) দুটি শহরের দূরত্ব 9,000 km. Fibre-এ আলোর গতি প্রায় 200,000 km/s ধরলে তাদের মধ্যে RTT-র তাত্ত্বিক সর্বনিম্ন মান কত?

45 ms
90 ms
60 ms
9 ms

(সহজ) কোন কাজে TCP-র বদলে UDP-ভিত্তিক নিজস্ব নিয়ম সবচেয়ে মানানসই?

টাকা পাঠানোর API
একটি বড় ফাইল download
Database replication
ভয়েস কল, যেখানে দেরিতে আসা packet অর্থহীন

(সহজ) কোন HTTP method safe এবং idempotent দুটিই?

GET
PUT
POST
PATCH

(মাঝারি) Token বৈধ, ব্যবহারকারী চেনা, তিনি ভাড়ার তালিকা দেখতে পারেন কিন্তু বদলানোর অনুমতি নেই — তবু PUT পাঠালেন। ঠিক উত্তর কোনটি?

403 Forbidden
401 Unauthorized
404 Not Found
409 Conflict

(মাঝারি) টিকিট বাতিলের ফেরতে ব্যাংকের কাজ লাগে, শেষ হতে প্রায় ২ দিন। বাতিলের অনুরোধের ঠিক উত্তর কোনটি?

200 OK, ফেরত শেষ বলে
201 Created, শুধু body-তে লেখা “অপেক্ষা করুন”
202 Accepted, সাথে ফেরতের অবস্থা দেখার ঠিকানা
অনুরোধটি ২ দিন খোলা রেখে শেষে 200

(কঠিন) Payment-এর POST timeout হলো; client একই Idempotency-Key আর একই body দিয়ে আবার পাঠাল। সার্ভারে প্রথম অনুরোধ আসলে সফলভাবে শেষ হয়েছিল। ঠিক আচরণ কোনটি?

নতুন একটি payment তৈরি করে 201
সবসময় 409, কারণ key আগে দেখা গেছে
422, কারণ retry নিষিদ্ধ
আগের সংরক্ষিত উত্তরই আবার — একই payment id, দ্বিতীয়বার টাকা কাটা নয়

(মাঝারি) লাখো সারির একটি feed, যার মাথায় অনবরত নতুন পোস্ট আসে। পাতা ভাগের সবচেয়ে ভালো কৌশল কোনটি?

?page=N দিয়ে offset আর limit
শুধু created_at-এর ওপর cursor
(created_at, id)-এর ওপর অস্বচ্ছ cursor (keyset)
পুরো তালিকা একবারে পাঠানো

(মাঝারি) GraphQL-এ ৫০টি post-এর তালিকা একটি query-তে আসে; লেখকের resolver প্রতিটি post-এর জন্য আলাদা query চালায়। মোট কয়টি database query, আর DataLoader-এর batching-এ কয়টি?

৫০টি, আর batching-এ ১টি
৫১টি, আর batching-এ ২টি
৫১টি, batching-এও ৫১টি
২টি, batching-এ ১টি

(সহজ) কোন ক্ষেত্রে gRPC সবচেয়ে মানানসই?

CDN-এ cache হওয়া উচিত এমন পাবলিক ব্রাউজার API
অনেক দলের, পর্দাভেদে আলাদা field চাওয়া mobile অ্যাপ
ছবি আর CSS-এর মতো static ফাইল দেওয়া
Data center-এর ভেতরে বহু ভাষার সার্ভিসের কম-latency আলাপ আর streaming

(কঠিন) Client-এর deadline 500 ms. সার্ভিস A নিজের 150 ms কাজ করে B-কে ডাকে; B নিজের 200 ms কাজ করে C-কে ডাকে। Deadline শিকলে এগিয়ে দিলে (network নগণ্য) C-র হাতে কত সময় থাকে?

500 ms
150 ms
300 ms
350 ms

(মাঝারি) ২ লাখ client প্রতি 5 s-এ short polling করে; খবর আসে এলোমেলো সময়ে। সার্ভারে সেকেন্ডে কতটি অনুরোধ, আর গড় দেরি কত (network বাদে)?

40,000 req/s, গড় দেরি 5 s
1,000,000 req/s, গড় দেরি 2.5 s
40,000 req/s, গড় দেরি 2.5 s
4,000 req/s, গড় দেরি 2.5 s

(সহজ) কোন কাজে WebSocket সবচেয়ে মানানসই?

Chat-এ দুই দিকে ঘনঘন ছোট বার্তা আর typing সংকেত
লাখো পাঠকের কাছে এক দিকে লাইভ স্কোর পাঠানো
দিনশেষের রিপোর্ট download
অ্যাপ বন্ধ থাকলেও ফোনে বিজ্ঞপ্তি পৌঁছানো

(কঠিন) Chat gateway-গুলো একটি Redis-ধাঁচের pub/sub backplane দিয়ে জোড়া। বার্তা publish হওয়ার মুহূর্তে প্রাপকের gateway সাময়িক বিচ্ছিন্ন ছিল। কী ঘটে, আর নকশায় কী লাগে?

Pub/sub বার্তা জমিয়ে রেখে পরে দেবে, বাড়তি কিছু লাগে না
TCP নিশ্চিত করবে যে বার্তা পৌঁছাবে
WebSocket নিজেই হারানো বার্তা আবার পাঠাবে
বার্তা হারাতে পারে — তাই আগে টেকসই store-এ লেখা আর reconnect-এ শেষ seq থেকে আনা

(মাঝারি) Backend আসল client-এর IP জানতে X-Forwarded-For header পড়ে। কোন নিয়মটি নিরাপদ?

শুধু চেনা proxy থেকে এলে মান নেওয়া, আর বাইরের proxy বাইরে থেকে আসা মান মুছে নিজের দেখা মান বসাবে
Header যা বলে, সবসময় বিশ্বাস করা
TCP-র উৎস IP-ই সবসময় আসল client
Header-এর সবচেয়ে বাঁয়ের ঠিকানাই সবসময় সঠিক

(সহজ) নতুন কোড (v2) পুরোনো কোডের (v1) লেখা ডেটা পড়তে পারে — এটি কোন সামঞ্জস্য?

Forward compatibility
Full compatibility
Breaking change
Backward compatibility

(মাঝারি) ৫০০টি বাংলা অক্ষরের (code point, পরিসর U+0980–U+09FF) একটি লেখা UTF-8-এ কত byte?

500
1,000
1,500
3,000

৪ · মডিউল ৩ — Scaling-এর মৌলিক (২১টি প্রশ্ন)

চাপ বাড়লে বড় হওয়া আর ভিড় সামলানো: horizontal scaling, stateless সার্ভিস, load balancer আর health check, session, consistent hashing, CDN আর load shedding. বেশি ভুল হয় hash mod N আর ring-এ key সরানো গুলিয়ে ফেলায়, আর health check-এর হিসাবে timeout বাদ দেওয়ায়।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ১৩–১৮

পর্ব ১৩ · Vertical বনাম horizontal scaling — stateless সার্ভিস, Amdahl আর USL, target tracking autoscaling
পর্ব ১৪ · Load balancing — L4 বনাম L7, round robin থেকে power of two choices, health check-এর হিসাব, rolling deploy
পর্ব ১৫ · Stateless বনাম stateful — sticky session, shared session store, cookie-র flag, JWT আর revocation
পর্ব ১৬ · Consistent hashing — hash mod N-এর ফাঁদ, ring, virtual node, rendezvous
পর্ব ১৭ · CDN আর edge — Cache-Control, hit ratio-র অঙ্ক, origin shield, purge
পর্ব ১৮ · Overload সামলানো — goodput, ধসের সময় T*, backpressure, 429 বনাম 503, retry-র গুণফল

(সহজ) “Stateless সার্ভিস” কথাটির সঠিক অর্থ কোনটি?

State সার্ভারের বাইরে — shared store-এ বা স্বাক্ষরিত token-এ
কোনো ডেটাই রাখে না, database লাগে না
প্রত্যেক ব্যবহারকারী সবসময় একই সার্ভারে
সার্ভারে কোনো cache রাখা নিষেধ

(কঠিন) Universal Scalability Law: C(N) = N ÷ (1 + σ(N − 1) + κN(N − 1)), যেখানে σ = 0.05 আর κ = 0.0005. মোটামুটি কতটি সার্ভারে throughput সর্বোচ্চ?

প্রায় ৪৪টি
প্রায় ২০টি
প্রায় ২,০০০টি
চূড়া নেই — throughput সবসময় বাড়ে

(সহজ) Target tracking autoscaling-এ লক্ষ্য instance-প্রতি 60% ব্যস্ততা। এখন ৮টি instance, গড় ব্যস্ততা 90%. নিয়ম ⌈বর্তমান সংখ্যা × বর্তমান মান ÷ লক্ষ্য⌉ হলে কতটি instance চাওয়া হবে?

৬টি
১২টি
৯টি
১৩টি

(মাঝারি) Autoscaler চাপ মেপে সাথে সাথে instance বাড়ায়-কমায়; কমানোর আগে কোনো stabilization window নেই। ঢেউয়ের মতো চাপে কী ঘটে?

খরচ কম, p99-ও স্থির
প্রভাব নেই — load balancer চাপ সমান ভাগ করে
বারবার বাড়া-কমা (flapping); warm-up শেষের আগেই instance সরে
Autoscaler নিজেই বন্ধ হয়ে যায়

(মাঝারি) Active health check: interval 5 s, timeout 2 s, পরপর ৩ বার ব্যর্থ হলে DOWN. একটি সার্ভার পুরো ঝুলে গেল। সবচেয়ে খারাপে কত সেকেন্ডে বাদ পড়বে?

৫ সেকেন্ড
১৫ সেকেন্ড
৬ সেকেন্ড
১৭ সেকেন্ড

(মাঝারি) ৮টি একই রকম সার্ভার, প্রতিটি 60% ব্যস্ত। Rolling deploy-এ একসাথে ২টি সরালে বাকিদের ব্যস্ততা মোটামুটি কত?

60%
প্রায় 68.6%
80%
75%

(কঠিন) দুটি সার্ভারের একটির ক্ষমতা অন্যটির অর্ধেক। মোট চাপ মিলিত ক্ষমতার 70%, load balancer plain round robin. কী ঘটবে?

দুটিই প্রায় 70% ব্যস্ত
ধীরটির চাপ তার ক্ষমতার প্রায় 105% — queue সীমাহীন বাড়ে
দ্রুতটি overload হবে
সমস্যা নেই — মোট ক্ষমতা চাহিদার বেশি

(মাঝারি) বড় fleet-এর সামনে কয়েক ডজন স্বাধীন load balancer, প্রত্যেকের হাতে ব্যস্ততার তথ্য কিছুটা পুরোনো। কোন algorithm সবচেয়ে মানায়?

Least connections
Plain round robin
Power of two random choices
Client IP-এর hash

(সহজ) Session cookie-র কোন attribute অন্য সাইট থেকে শুরু হওয়া অনুরোধে cookie পাঠানো সীমিত করে CSRF-এর ঝুঁকি কমায়?

HttpOnly
SameSite=Lax বা Strict
Secure
Max-Age

(সহজ) নিচের কোনটি sticky session-এর দাম নয়?

সার্ভার পড়লে তার সব session হারায়
নতুন সার্ভারে পুরোনো ব্যবহারকারীরা যান না, ভার অসম
Deploy আর scale in কঠিন
প্রতি অনুরোধে session পড়তে বাড়তি network hop

(মাঝারি) দাবি: “JWT হলে কোনো store লাগবে না, logout-ও সঙ্গে সঙ্গে কার্যকর।” কোন মন্তব্যটি সঠিক?

Token exp পর্যন্ত বৈধ; সঙ্গে সঙ্গে বাতিলে deny list বা token version — অর্থাৎ store লাগে
ঠিক — logout-এ token-এর স্বাক্ষর অচল হয়
ঠিক, যদি payload এনক্রিপ্ট করা থাকে
Refresh token বাতিলেই access token-ও অচল

(মাঝারি) Cache cluster-এ key-এর সার্ভার = hash(key) mod N. সার্ভার ৯টি থেকে ১০টি হলো (hash ভালোভাবে ছড়ানো)। মোটামুটি কত ভাগ key সরবে?

প্রায় 10%
প্রায় 90%
প্রায় 50%
প্রায় 11%

(মাঝারি) Ring-এ ১৯টি সার্ভার, এলোমেলো অবস্থানে (virtual node নেই)। বিশতম যোগ করলে প্রত্যাশিতভাবে কী ঘটে?

প্রায় 5% সরে, পুরোনোদের মধ্যেও অদলবদল
প্রায় 95% key সরে
প্রায় 5% key সরে, সবাই নতুন সার্ভারে
প্রতিটি পুরোনো সার্ভার সমান সংখ্যক key হারায়

(কঠিন) Virtual node-সহ ring-এ প্রতি সার্ভারের key-সংখ্যার sd ÷ গড় ≈ 1 ÷ √V (V = সার্ভারপ্রতি virtual node). অনুপাতটি প্রায় 5% রাখতে V কত?

২০
৪০
৪০০
৪,০০০

(মাঝারি) Consistent hashing নিয়ে কোন দাবিটি ভুল?

V বাড়ালে একটি hot key-এর চাপও অনেক সার্ভারে ছড়ায়
সার্ভার বাদ পড়লে শুধু তার key অন্যত্র যায়
Rendezvous hashing-এ vnode ছাড়াই ভাগ প্রায় সমান
Lookup-এ সাজানো token array-তে binary search চলে

(মাঝারি) সবার জন্য একই একটি API উত্তর ব্রাউজারে ৬০ সেকেন্ড আর CDN-এ ১ ঘণ্টা থাকবে; বদলালে CDN purge. কোন Cache-Control?

public, max-age=3600
private, max-age=60
no-store
public, max-age=60, s-maxage=3600

(মাঝারি) ব্যালান্সসহ dashboard-এর উত্তরে Cache-Control: public, s-maxage=60. CDN-এর পেছনে সবচেয়ে বড় ঝুঁকি?

একজনের পাতা shared cache থেকে অন্যজনকে দেখানো
ঝুঁকি নেই — origin-এর ভার কমবে
Browser পাতাটি একদমই cache করবে না
শুধু ৬০ সেকেন্ড পুরোনো ব্যালান্স দেখাবে

(কঠিন) ২৫টি edge-এর সবকটিতে একটি ছবি সারাক্ষণ চাওয়া হয়; TTL ৩০০ সেকেন্ড, প্রতিটি edge আলাদাভাবে miss করে। ঘণ্টায় origin ছবিটি কতবার দেয় — shield ছাড়া, আর shield-সহ?

৩০০ আর ১২
২৫ আর ১
৩০০ আর ৩০০
১২ আর ১২

(মাঝারি) ক্ষমতা μ = 500/s, আসছে λ = 600/s, queue অসীম (FIFO), timeout 1 s. খালি queue থেকে কত সেকেন্ড পরে নতুন অনুরোধ timeout হতে শুরু করবে?

প্রায় ১ সেকেন্ড
প্রায় ০.২ সেকেন্ড
কখনো নয় — সার্ভার পুরো গতিতে চলছে
প্রায় ৫ সেকেন্ড

(কঠিন) একটি অনুরোধের কাজ S = 10 ms, ফেরাতে লাগে তার 10% (c = 0.1). λ = 500/s হলে সার্ভার সেকেন্ডে কতটি গ্রহণ করতে পারে? সূত্র a = (1 − λcS) ÷ (S(1 − c)).

১০০
৫০
০
প্রায় ৫৬

(সহজ) পরামর্শ: “interactive API-র সামনে অসীম queue বসান, কিছুই হারাবে না।” কোনটি সঠিক?

Queue যত বড়, goodput তত বেশি
অপেক্ষা সীমাহীন বাড়ে, উত্তর timeout-এর পরে আসে — সীমিত queue আর দ্রুত ফেরানো ভালো
ঝুঁকি শুধু memory; RAM বাড়ালেই হবে
Queue থাকলে retry লাগে না, চাপ কমে

৫ · মডিউল ৪ — ডেটা স্টোরেজ (২৯টি প্রশ্ন)

ডেটা কোথায় আর কীভাবে রাখবেন: storage engine, database বাছাই, index, কপি, ভাগ, transaction, কয়েক সেবা জুড়ে লেনদেন, object storage আর search. বেশি ভুল হয় replication-কে লেখা বাড়ানোর উপায় ভাবায়, snapshot isolation-কে serializable ভাবায়, আর 2PC-এর blocking ভোলায়।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ১৯–২৭

পর্ব ১৯ · Storage engine — B-tree বনাম LSM-tree, WAL আর group commit, fan-out ও উচ্চতা, row বনাম column store
পর্ব ২০ · SQL বনাম NoSQL — key-value, document, wide-column, graph; embed বনাম reference; দুই “consistency”
পর্ব ২১ · Index আর query performance — composite, leftmost prefix, covering index, EXPLAIN, index ভেস্তে দেওয়ার ভুল
পর্ব ২২ · Replication — sync বনাম async, replication lag, read-your-writes, failover আর হারানো লেখা
পর্ব ২৩ · Partitioning আর sharding — range বনাম hash, hot key, rebalancing, scatter-gather, Snowflake ID
পর্ব ২৪ · Transaction আর isolation level — anomaly, lost update, write skew, MVCC, version কলাম
পর্ব ২৫ · Distributed transaction — 2PC-এর commit point ও blocking, saga-র compensation, outbox
পর্ব ২৬ · Object storage — object-এর মডেল, presigned URL, erasure coding-এর জায়গা ও মেরামত
পর্ব ২৭ · Search — inverted index, BM25, segment, autocomplete trie, derived copy

(সহজ) কোন workload-এ LSM-tree সাধারণত B-tree-এর চেয়ে ভালো মানায়?

বিপুল হারে লেখা, পড়া মূলত key দিয়ে
ঘনঘন range scan আর অনুমানযোগ্য p99 পড়া
কম লেখা, জায়গায় ছোট update
প্রায়ই অনুপস্থিত key খোঁজা

(মাঝারি) একটি B+-tree-এর প্রতিটি node-এর fan-out ১,০০০. ১০০ কোটি (10⁹) key রাখতে root থেকে leaf পর্যন্ত কমপক্ষে কয়টি স্তর লাগে?

৩টি
৪টি
৩০টি
৯টি

(মাঝারি) প্রতিটি fsync-এ 4 ms লাগে; group commit-এ গড়ে ১০টি commit এক fsync-এ যায়। Log-টি সেকেন্ডে সর্বোচ্চ প্রায় কয়টি commit নেয়?

২৫০টি
২,৫০০টি
২৫টি
৪০টি

(সহজ) ৪০টি সমান আকারের কলাম, compression নেই; query পড়ে ৪টি কলাম। Row store-এর তুলনায় column store কত ভাগ byte পড়বে?

৪%
১০%
২৫%
১০০% — scan মানেই পুরো টেবিল

(মাঝারি) বাস-টিকিট সেবার সিট-বুকিং আর পেমেন্ট: একই সিট দুজন পাবেন না, আর প্রায়ই নতুন রিপোর্ট লাগে। কোন store মানায়?

Eventual-consistent key-value store, শর্ত ছাড়া
Graph database
শর্তযুক্ত update বা constraint-সহ একটি relational database
Search engine-কে মূল store বানানো

(মাঝারি) “Wide-column store” আর “column store” নিয়ে কোনটি ঠিক?

দুটি একই জিনিসের দুই নাম
Wide-column-এ join আর অজানা প্রশ্ন সস্তা
Column store এক-এক সারির লেখায় দ্রুততম
Wide-column সারি রাখে partition ধরে; column store ডেটা রাখে কলাম ধরে, বিশ্লেষণের জন্য

(সহজ) Index আছে (customer_id, created_at). নিচের কোন শর্তে এই index দিয়ে খোঁজা (seek) সম্ভব নয়?

WHERE customer_id = 7
WHERE created_at >= '2026-01-01'
WHERE customer_id = 7 AND created_at >= '2026-01-01'
WHERE customer_id = 7 ORDER BY created_at

(মাঝারি) Query: SELECT amount FROM orders WHERE customer_id = ? AND created_at > ?. কোন index দিলে টেবিলে না গিয়েই উত্তর মেলে?

(created_at, customer_id)
(customer_id)
(customer_id, created_at, amount)
(amount)

(মাঝারি) created_at কলামে index আছে, তবু WHERE date(created_at) = '2026-03-15'-এর plan বলছে SCAN. মূল কারণ কী?

Index-টি নষ্ট হয়ে গেছে, আবার বানাতে হবে
কলামে function বসায় সাজানো মান কাজে লাগে না
তারিখের কলামে B-tree index চলে না
সারি কম, তাই optimiser index নেয় না

(মাঝারি) প্রতিটি node সেকেন্ডে 10,000 operation সামলায়; লেখা 4,000/s, পড়া 24,000/s. প্রতিটি follower সব লেখা প্রয়োগ করে, leader-ও পড়া নেয়। Single-leader-এ কমপক্ষে কয়টি node?

৪টি
৩টি
৫টি
কোনো সংখ্যাতেই সম্ভব নয়

(সহজ) রিনা ছবি বদলে সাথে সাথে refresh করে পুরোনো ছবি দেখলেন; পড়া আসে async replica থেকে। কোন নিশ্চয়তা ভাঙল, প্রতিকার কী?

Monotonic reads; সব পড়া একটি replica-তে বাঁধা
Consistent prefix; সব লেখা এক partition-এ
Durability; fsync চালু করা
Read-your-writes; নিজের সদ্য-বদলানো ডেটা কিছুক্ষণ leader থেকে পড়া

(মাঝারি) Async replication: leader ৫,০০০ নম্বর লেখা পর্যন্ত “OK” দিয়ে মারা গেল; F1-এ আছে ৪,৯৮৮ পর্যন্ত, F2-তে ৪,৯৭০. এগিয়ে থাকা follower promote হলে কয়টি “সফল” লেখা হারায়?

০টি
৩০টি
১৮টি
১২টি

(কঠিন) Failover-এর পরে পুরোনো leader নেটওয়ার্কে ফিরে এসে এখনো লেখা নিচ্ছে। এই split brain ঠেকানোর মূল উপায় কোনটি?

পরে LWW দিয়ে মিলিয়ে নেওয়া
নতুন epoch নম্বর; পুরোনো epoch-এর লেখা বাতিল (fencing)
Failover-এর timeout আরও ছোট করা
দুজনকেই চলতে দেওয়া — multi-leader-এর মতো

(সহজ) একটি messages table range partitioning-এ created_at দিয়ে ভাগ করা — প্রতিটি shard একটি সময়ের পরিসর। কী ঘটবে?

লেখা সব shard-এ সমানভাবে ছড়ায়
সময়ের পরিসরে range scan সব shard-এ যেতে হয়
নতুন লেখা প্রায় সব শেষ shard-এ যায়, সেটি hot spot হয়
Hot key কখনো তৈরি হয় না

(মাঝারি) ৫১২টি fixed partition ৮টি node-এ; নবম node এলে সমান ভাগ করা হলো। hash(key) mod N-এ (N: 8 → 9) কত key সরত? দুটির তুলনা:

দুটিতেই প্রায় ১১%
fixed partitions প্রায় ৮৯%, mod N প্রায় ১১%
দুটিতেই ৫০%
fixed partitions প্রায় ১১%, mod N প্রায় ৮৯%

(মাঝারি) একটি Snowflake-ধাঁচের 64-bit ID-তে 41 bit millisecond সময়, 10 bit worker আর 12 bit sequence. একটি worker সেকেন্ডে সর্বোচ্চ প্রায় কয়টি ID দিতে পারে?

প্রায় ৪১ লাখ (4,096,000)
৪,০৯৬টি
4,194,304
১,০২৪টি

(কঠিন) একই Snowflake নকশায় (41 bit millisecond, epoch থেকে গোনা) সময়ের অংশ মোটামুটি কত বছর পরে ফুরায়?

প্রায় ৩৫ বছর
প্রায় ২৫ দিন
প্রায় ১৩৯ বছর
প্রায় ৭০ বছর

(মাঝারি) একটি সেলিব্রিটির user:1 key একাই একটি shard-এ গড়ের কয়েক গুণ চাপ আনছে। প্রচলিত প্রতিকার কোনটি?

আরও node যোগ করে hash ring বড় করা
Key-এ ছোট suffix (salting) যোগ করে কয়েক partition-এ ছড়ানো
Range ভাগে বদলানো
Replication factor কমানো

(সহজ) দুটি request একই wallet-এর ব্যালান্স ১,০০০ পড়ে অ্যাপে হিসাব করে লিখল ৭০০ আর ৬০০; একটি উত্তোলন হারাল। Anomaly-টি কী?

Dirty read
Phantom
Write skew
Lost update

(মাঝারি) Snapshot isolation-এ দুই ডাক্তার একসাথে on-call গুনলেন ২, তারপর প্রত্যেকে নিজের সারিতে on_call = 0 লিখলেন। কী হবে?

দুজনেরই commit, কেউ on call নেই — write skew
দ্বিতীয়জন first-committer-wins-এ abort
Deadlock হবে, database একজনকে বাতিল করবে
Dirty read হবে

(মাঝারি) ফ্ল্যাশ সেলে মজুতের একটি সারিতে প্রতিটি বিক্রি গড়ে 8 ms lock ধরে। ওই সারিতে সেকেন্ডে সর্বোচ্চ কয়টি বিক্রি?

৮টি
১২৫টি
১,২৫০টি
সার্ভার যত, তত গুণ

(কঠিন) UPDATE profiles SET bio = ?, version = version + 1 WHERE id = 42 AND version = 7 চালিয়ে ফল এলো “০টি সারি বদলেছে”, অথচ সারিটি আছে। অ্যাপের ঠিক কাজ কী?

সফল না হওয়া পর্যন্ত একই UPDATE
Version শর্ত বাদ দিয়ে লিখে দেওয়া
নতুন করে পড়ে বদল আবার প্রয়োগ, বা সংঘাত দেখানো
Database-এ bug — রিপোর্ট করা

(সহজ) মৌলিক two-phase commit-এ একজন participant YES ভোট দিয়েছে, তারপর coordinator-এর খবর নেই। সে কী করতে পারে?

Timeout হলে নিজেই abort
Timeout হলে নিজেই commit
অন্য participant-দের ভোট গুনে সংখ্যাগরিষ্ঠের পথে চলা
Lock ধরে সিদ্ধান্তের অপেক্ষা — সে in-doubt, blocked

(কঠিন) 2PC-তে coordinator থেকে প্রতিটি participant-এর RTT 40 ms, প্রতিটি forced log write 2 ms, participant-রা সমান্তরালে কাজ করে। PREPARE পাঠানো থেকে commit point পর্যন্ত প্রায় কত সময়?

40 ms
44 ms
46 ms
86 ms

(মাঝারি) একটি saga-র ধাপ T1, T2, T3, T4; compensation C1, C2, C3. T1 আর T2 commit হয়েছে, T3 স্থায়ীভাবে ব্যর্থ। Backward recovery-তে কী চলবে?

C1, তারপর C2
C3, C2, C1
C2, তারপর C1
ডেটাবেস নিজেই সব rollback করবে

(মাঝারি) অর্ডার commit-এর পরে broker-এ OrderPlaced পাঠাতে গিয়ে মাঝখানে crash হলে event হারায়। Transactional outbox কীভাবে সারায়?

Event-ও একই local transaction-এ outbox সারি হিসেবে লেখা; relay পরে পাঠায়
আগে event পাঠানো, তারপর database commit
Broker-কে XA-র participant বানিয়ে 2PC
Retry বাড়িয়ে দেওয়া

(মাঝারি) ১০০ TB ডেটা — ৩ কপি replication বনাম RS(6,3) erasure coding. মোট disk-এর জায়গা আর কয়টি fragment বা কপি হারানো সয়?

৩০০ TB, ২টি বনাম ১৫০ TB, ৩টি
৩০০ TB, ৩টি বনাম ১৫০ TB, ৬টি
৩০০ TB, ২টি বনাম ৯০০ TB, ৩টি
২০০ TB, ২টি বনাম ১৫০ TB, ৩টি

(কঠিন) Erasure coding-এ জায়গা কম লাগে। তার বিনিময়ে কোন দাম দিতে হয়?

Durability কপির চেয়ে সবসময় কম
সাধারণ পড়ায় সবসময় decode লাগে
একটি fragment মেরামতে k টি fragment পড়া — repair traffic বেশি
Bit rot ধরা যায় না

(সহজ) Autocomplete trie-র প্রতিটি node-এ সেরা ৫টি পরামর্শ আগে থেকে রাখা। একটি prefix-এর উত্তরের খরচ কিসের ওপর নির্ভর করে?

Prefix-এর নিচের পুরো subtree-র আকার
মোট সংরক্ষিত query-র সংখ্যা
Prefix-এর দৈর্ঘ্য — শুধু সেই পথে নামা
প্রতিটি পরামর্শের BM25 স্কোর নতুন করে হিসাব

৬ · মডিউল ৫ — Caching (১৩টি প্রশ্ন)

Cache-এর তিন প্রশ্ন: পড়া-লেখার কৌশল (cache-aside, read-through, write-through, write-behind), সরানো (eviction, TTL, invalidation), আর ছড়ানো cache (hot key, node বিকল)। বেশি ভুল হয় hit ratio-র অল্প বদলকে “সামান্য” ভাবায়, আর cache-aside-এর race না দেখায়।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ২৮–৩০

পর্ব ২৮ · Caching কৌশল — গড় latency-র সূত্র, cache-aside বনাম read-through, write-through/behind/around, stale set-এর race আর lease
পর্ব ২৯ · Eviction আর invalidation — LRU-র ভেতর, LFU আর scan, TTL jitter, cache stampede, penetration আর avalanche
পর্ব ৩০ · Distributed cache — shard বিকলের ধাক্কা, hot key আর L1, বহু স্তরের staleness, cache কখনো সত্যের উৎস নয়

(সহজ) Cache-aside আর read-through-এর মূল পার্থক্য কোনটি?

Miss-এ database-এ কে যায় — cache-aside-এ app, read-through-এ cache-এর loader
Read-through-এ লেখা আগে cache-এ যায়, পরে database-এ
Cache-aside-এ TTL লাগে না
Read-through কখনো পুরোনো মান দেয় না

(সহজ) Cache lookup 2 ms, database query 30 ms; miss হলে আগে cache দেখে তারপর database. Hit ratio 80% হলে গড় পড়ার latency কত?

7.6 ms
6 ms
26 ms
8 ms

(মাঝারি) সেকেন্ডে ৫০,০০০ পড়া আসে, আর database সর্বোচ্চ সেকেন্ডে ৪,০০০ query সামলাতে পারে। Cache-এর hit ratio অন্তত কত হতে হবে?

8%
80%
92%
99.2%

(মাঝারি) Cache-aside সিস্টেমে একটি মান বদলানোর সময় সাধারণত কোন ক্রম সবচেয়ে নিরাপদ বলে ধরা হয়?

আগে cache delete, তারপর database update
Database update, তারপর cache-এ নতুন মান SET
Database commit, তারপর cache delete; সাথে TTL, দরকারে lease
আগে cache-এ লেখা, পরে database-এ

(কঠিন) Cache-aside, TTL ১০ মিনিট। পাঠক A miss পেয়ে database থেকে v1 পড়লেন, set-এর আগে থামলেন। লেখক v2 commit করে key delete করলেন। তারপর A v1 set করলেন। এরপর?

TTL শেষ হওয়া পর্যন্ত সবাই পুরোনো v1 পাবেন
পরের পাঠকেরা v2 পাবেন — delete তো হয়েছে
Cache নিজে v1 আর v2 মেলাবে
A-র set ব্যর্থ হবে — key নেই

(সহজ) Eviction আর invalidation নিয়ে কোনটি সত্য?

ভুল eviction policy-তে ব্যবহারকারী ভুল মান দেখেন
TTL থাকলে invalidation-এর দরকার নেই
খারাপ eviction policy শুধু বেশি miss আনে; হারানো invalidation ভুল (পুরোনো) উত্তর দেখায়
Eviction আর invalidation একই কাজের দুই নাম

(মাঝারি) ধারণক্ষমতা ৩-এর একটি LRU cache-এ ক্রমে চলে: put A, put B, put C, get B, put D, get A (miss, তাই load), put E. E ঢোকানোর সময় কোন key বাদ পড়ে?

(মাঝারি) ৫০,০০০টি key একই মুহূর্তে লেখা হলো, TTL ৩০০ s ± 20%, jitter সমবণ্টিত। গড়ে সেকেন্ডে কতটির মেয়াদ শেষ হবে?

প্রায় ৪১৭
প্রায় ১৬৭
প্রায় ৮৩৩
৫০,০০০ — সব একই সেকেন্ডে

(কঠিন) Hot key-তে সেকেন্ডে ৩,০০০ অনুরোধ, recompute-এ 40 ms, কোনো সুরক্ষা নেই। মেয়াদের মুহূর্তে কতটি একই query database-এ যায়, আর single-flight lock দিলে?

প্রায় ৭৫, lock দিলে ১
৩,০০০, lock দিলে ১২০
প্রায় ১২০, lock দিলে ১
১ — cache নিজেই miss মেলায়

(মাঝারি) ১০টি shard-এর cache cluster, replica নেই, hit ratio 90%, key সমানভাবে ছড়ানো। একটি shard হঠাৎ বন্ধ হলে database-এর পড়ার চাপ স্বাভাবিকের কত গুণ হবে?

১০ গুণ
১.৯ গুণ
৯ গুণ
১.০৯ গুণ

(মাঝারি) উত্তর তিন স্তর পেরিয়ে আসে: CDN-এ TTL ১২০ s, L1-এ ১০ s, distributed cache-এ ৩০০ s; invalidation নেই। Database বদলালে সবচেয়ে খারাপে কতক্ষণ পুরোনো মান দেখা যেতে পারে?

৩০০ s
১০ s
প্রায় ১৪৩ s
৪৩০ s

(কঠিন) ৪০টি app server-এর প্রতিটিতে hot key-এর L1 কপি, TTL 2 s, coalescing চালু। Key-টিতে মোট ৬০,০০০ পড়া/s. Distributed cache-এ এই key-এর অনুরোধ/s কত?

প্রায় ১,৫০০
প্রায় ২০
প্রায় ৪০
প্রায় ৩০,০০০

(সহজ) Shopping cart রাখা হয় শুধু Redis-এ, database-এ নয়; একই cluster-এ cache-এর জন্য allkeys-lru eviction চালু। সবচেয়ে বড় ঝুঁকি?

Cart পড়া ধীর হবে
Hot key তৈরি হবে
Consistent hashing কাজ করবে না
Memory ভরলে eviction সক্রিয় cart মুছবে, ফেরানোর উৎস নেই

৭ · মডিউল ৬ — Messaging আর stream (২৫টি প্রশ্ন)

বার্তা কোথায় জমে, কে কখন “পড়েছি” বলে, আর crash-এর পরে কী আবার ঘটে। বেশি ভুল হয় at-least-once-কে “একবারই” ভাবায়, partition-এর বাইরে ক্রম আশা করায়, আর broker-এর “exactly-once”-কে টাকা বা SMS পর্যন্ত টেনে নেওয়ায়। প্রতিটি দৃশ্যে জিজ্ঞেস করুন: effect-এর পরে, ack-এর আগে crash হলে কী হবে?

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ৩১–৩৭

পর্ব ৩১ · Message queue — ack, visibility timeout, retry, poison message, DLQ আর consumer-এর সংখ্যা
পর্ব ৩২ · Pub/sub আর event-driven architecture — fan-out-এর খরচ, event বনাম command, choreography বনাম orchestration
পর্ব ৩৩ · Log-ভিত্তিক streaming — key আর partition-এর ক্রম, offset commit, consumer group, lag আর acks
পর্ব ৩৪ · Delivery semantics — at-most/at-least/exactly-once, idempotency key, inbox আর dedup window
পর্ব ৩৫ · Event sourcing আর CQRS — expected version, snapshot, upcasting আর পিছিয়ে থাকা read model
পর্ব ৩৬ · Batch আর stream processing — MapReduce-এর combiner, event time, window আর watermark
পর্ব ৩৭ · Background job আর workflow engine — স্তরে স্তরে retry, lease, cron আর deterministic replay

(সহজ) কোন কাজটি message queue-র পেছনে রাখা সবচেয়ে কম মানানসই?

অর্ডারের পরে রসিদের PDF বানানো
লগইনে password যাচাই
আপলোড করা ছবি ছোট করা
রাতের রিপোর্টের জন্য ঘটনা জমানো

(সহজ) Queue-তে ২ মিনিট ধরে 900 msg/s আসছে; ৮ জন consumer, প্রত্যেকে 100 msg/s শেষ করেন। শুরুতে খালি থাকলে ২ মিনিট পরে জমা কত?

1,08,000
96,000
100
12,000

(মাঝারি) বার্তা আসে 800/s, আর একজন consumer প্রতি সেকেন্ডে 25টি শেষ করেন। প্রত্যেককে গড়ে ৮০% ব্যস্ত রাখতে কতজন লাগবে?

৩২ জন
৪০ জন
২৬ জন
১,০০০ জন

(কঠিন) Visibility timeout ১৫ সেকেন্ড, তিনবার ব্যর্থ হলে DLQ; সুস্থ job-এ লাগে ৪০ সেকেন্ড, worker সময় বাড়ায় না। Crash ছাড়াই কী ঘটবে?

Broker নিজেই timeout বাড়িয়ে দেবে
কিছুই হবে না, কারণ crash হয়নি
একই job কয়েকজন চালাবেন, আর সুস্থ job-ও DLQ-তে যেতে পারে
বার্তাটি হারিয়ে যাবে

(সহজ) কোন বার্তার নামটি event নয়, command?

UserRegistered
PaymentFailed
SeatReleased
SendWelcomeEmail

(মাঝারি) একটি topic-এ 2,000 event/s, প্রতিটি 3 KB, আর ৫টি subscription সব event চায়। বাইরে যাওয়া মোট bandwidth কত (1 MB = 1,000 KB)?

30 MB/s
6 MB/s
10 MB/s
30,000 MB/s

(মাঝারি) পাঁচ সেবার একটি বুকিং প্রবাহে প্রতিটি ধাপে timeout, ব্যর্থতায় উল্টো ক্রমে compensation, আর support-কে বলতে হয় “অর্ডারটি কোন ধাপে”। কোন নকশা মানায়?

Choreography — প্রতিটি সেবা আগের event শুনে কাজ করে
পাঁচ সেবাকে এক 2PC transaction-এ বাঁধা
প্রতিটি সেবা পরেরটিকে সরাসরি HTTP-তে ডাকবে
Orchestration — একজন orchestrator command পাঠায়, উত্তর লেখে, timer চালায়

(সহজ) একটি topic-এ 12টি partition, একটি consumer group-এ consumer আছেন ২০ জন। কতজন কাজ পাবেন?

২০ জন, record ভাগ করে
১০ জন, প্রতি partition-এ দুজন
১ জন, বাকিরা standby
১২ জন; ৮ জন অলস

(মাঝারি) চালকের অবস্থানের event-এ key = city; ঢাকার partition সবসময় পিছিয়ে। ভালো সমাধান কোনটি?

Key পুরো বাদ দেওয়া
Key = driver_id
ঢাকার partition-এ আরও consumer
Partition দ্বিগুণ, key একই রেখে

(মাঝারি) Consumer প্রতিটি record প্রক্রিয়ার পরে offset commit করেন। Offset 45-এর effect লেখা শেষ, কিন্তু commit-এর আগেই crash হলো। নতুন মালিক কোথা থেকে শুরু করবেন?

45 থেকে — 45-এর effect দুবার হবে
46 থেকে — duplicate নেই
Batch-এর শুরু থেকে
পরের batch থেকে — বাকিগুলো হারাবে

(সহজ) একটি consumer group প্রতি সেকেন্ডে 2,000টি record শেষ করে। ৫ মিনিট ধরে 2,500 record/s এল, শুরুতে lag শূন্য। শেষে lag কত?

7,50,000
6,00,000
500
1,50,000

(কঠিন) Replication factor 3, acks=all, কিন্তু min.insync.replicas = 1. দুটি follower ISR থেকে বেরিয়ে গেলে কী সত্য?

লেখা চলবে, ack আসবে শুধু leader লিখলেই — কার্যত acks=1
Broker লেখা প্রত্যাখ্যান করবে
acks=all থাকায় ডেটা হারানো অসম্ভব
Producer নিজে acks=0-তে নামবে

(মাঝারি) হারাতে পারে এমন network-এ “exactly-once delivery” কেন অসম্ভব?

Broker যথেষ্ট দ্রুত নয়
TCP ক্রম রক্ষা করে না
Ack-এর ack নিলেই মেটে
উত্তর না এলে প্রেরক জানেন না বার্তা হারাল নাকি ack

(কঠিন) Consumer আগে Redis-এ SETNX দিয়ে message id চিহ্নিত করে, তারপর আলাদা database-এ টাকা যোগ করে। মাঝে crash হলে redelivery-তে কী হবে?

টাকা দুবার যোগ হবে
চিহ্ন আছে বলে বার্তা বাদ — টাকা কখনো যোগ হবে না
ঠিক একবার, কারণ SETNX atomic
Broker নিজে চিহ্ন মুছে দেবে

(মাঝারি) 500 msg/s, dedup window ২ দিন (১ দিন = 86,400 সেকেন্ড), প্রতি entry 50 byte, store-এর ৩টি কপি। মোট মেমরি কত?

4.32 GB
6.48 GB
12.96 GB
0.27 GB

(মাঝারি) দাবি: “broker-এ exactly-once চালু, তাই গ্রাহক কখনো দুটি SMS পাবেন না।” সমস্যা কী?

Broker-এর নিশ্চয়তা তার ভেতরেই; SMS পাঠানো আর ack-এর মাঝে crash হলে আবার পাঠানো হবে
সমস্যা নেই — broker duplicate SMS আটকায়
শুধু latency বাড়ে
Exactly-once চালু করলে বার্তা হারায়

(সহজ) Event sourcing আর CQRS নিয়ে কোনটি সত্য?

দুটি আলাদা ধারণা; একটি ছাড়া অন্যটি চলে
CQRS মানেই event sourcing
Event sourcing-এ read model নিষেধ
দুটিই পুরো সিস্টেমে চালু করতে হয়

(সহজ) একটি stream-এ 3,470টি event, snapshot নেওয়া হয় প্রতি 500টিতে। লোডে শেষ snapshot-এর পরে কয়টি event replay লাগবে?

৩,৪৭০টি
৩০টি
৫০০টি
৪৭০টি

(কঠিন) বাস-টিকিট অ্যাপে “সিট খালি কি না” পিছিয়ে থাকা search read model দেখে বুকিং নেওয়া হয়। ঝুঁকি আর প্রতিকার কী?

Double booking; নিয়ম যাচাই write model-এ, expected version দিয়ে
ঝুঁকি নেই, event store append-only
শুধু ধীরগতি; projector দ্রুত করলেই চলে
Read model-এ cache যোগ করা

(মাঝারি) Click মিনিট 1, 4, 8, 15, 17, 30-এ; session gap 5 মিনিট (আগের click-এর ৫ মিনিটের মধ্যে হলে একই session ধরা হয়)। কয়টি session?

৪টি
৬টি
৩টি
২টি

(কঠিন) ১ মিনিটের tumbling window; watermark = সর্বোচ্চ event time − 30 s; allowed lateness নেই। সর্বোচ্চ event time 10:05:40. এখন 10:04:55-এর একটি ঘটনা এলে?

[10:04, 10:05)-এ গোনা হবে
Late — [10:04, 10:05) বন্ধ, ঘটনা বাদ বা side output-এ
[10:05, 10:06)-এ গোনা হবে
Watermark পিছিয়ে window আবার খুলবে

(সহজ) MapReduce-এ কোন reduce ফাংশন বদল ছাড়াই combiner হিসেবে চালানো নিরাপদ?

গড় (average)
মধ্যমা (median)
সর্বোচ্চ মান (max)
প্রথম দেখা মান রাখা

(মাঝারি) প্রতি ১৫ মিনিটের একটি job একদিন ২০ মিনিট নিল; overlap policy “Allow” রাখা। কী ঘটতে পারে?

কিছুই না — scheduler নিজেই আগেরটির শেষের অপেক্ষা করে
Interval ৫ মিনিট করলে সমস্যা মিটবে
Run-এর ওপর run জমে আরও ধীর; ভালো নীতি Forbid, বা lease-সহ একটি run
দুটি run কাজ নিজেরাই ভাগ করে নেবে

(মাঝারি) Replay-ভিত্তিক workflow engine-এ workflow function সরাসরি Date.now() দেখে শাখা বাছে। Worker crash-এর পরে কী সমস্যা?

সমস্যা নেই — engine সব activity আবার চালায়
Replay-তে অন্য শাখা বাছতে পারে, কোড history-র সাথে মেলে না
শুধু log-এ ভিন্ন সময় দেখাবে
Workflow দ্রুত হবে

(মাঝারি) তিনটি সার্ভারে একই crontab, প্রতিটি রাত ২টায় “দৈনিক বিল” job চালায়। সবচেয়ে নিরাপদ নকশা কোনটি?

শুধু একটি সার্ভারে crontab রাখা
তিনটিই চলুক, পরে ঠিক করা যাবে
Lease দিয়ে একজন scheduler, সাথে job + তারিখের unique key
তিন সার্ভারের ঘড়ি একটু আলাদা করা

৮ · মডিউল ৭ — Distributed systems-এর তত্ত্ব (৩২টি প্রশ্ন)

এই অংশের প্রশ্ন distributed systems-এর তত্ত্ব যাচাই করে: partial failure আর অনির্ভরযোগ্য ঘড়ি, Lamport ও vector clock, CAP আর PACELC, quorum, Raft, fencing token, gossip, sketch আর CRDT. সবচেয়ে বেশি ভুল হয় চার জায়গায়: CAP-এর C-কে ACID-এর C ভাবা, R + W > N-কে linearizability ভাবা, Raft-এর majority গুনতে leader-কে বাদ দেওয়া, আর lease-এর মেয়াদকেই নিরাপত্তা ভাবা।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ৩৮–৪৬

পর্ব ৩৮ · Distributed system-এর কঠিন সত্য আর পর্ব ৩৯ · সময় আর ক্রম — অজানা ফল, ঘড়ির drift, FLP, NTP-র offset, Lamport আর vector clock
পর্ব ৪০ · CAP, PACELC আর consistency model — CAP-এর সঠিক ব্যাখ্যা, linearizable বনাম sequential, session guarantee
পর্ব ৪১ · Quorum আর leaderless replication আর পর্ব ৪২ · Consensus আর Raft — R + W > N, sloppy quorum, majority, election আর commit
পর্ব ৪৩ · Coordination আর পর্ব ৪৪ · Membership আর failure detection — lease, fencing token, heartbeat-এর খরচ, SWIM
পর্ব ৪৫ · Probabilistic data structure আর পর্ব ৪৬ · Conflict resolution আর CRDT — Bloom, count-min আর HyperLogLog-এর সূত্র, LWW, G-Counter, OR-Set

(সহজ) “২,০০০ টাকা পাঠান” অনুরোধের উত্তর timeout-এর আগে এল না। সবচেয়ে নিরাপদ পরের কাজ কোনটি?

ধরে নেওয়া যে টাকা যায়নি, তাই নতুন অনুরোধ পাঠানো
একই idempotency key দিয়ে আবার পাঠানো, বা অবস্থা জিজ্ঞেস করা
ধরে নেওয়া যে টাকা গেছে, আর সফল দেখানো
Timeout অসীম করা

(মাঝারি) দুটি ঘড়ি মেলানো হলো; একটি +20 ppm, অন্যটি −20 ppm হারে সরে। ১ দিন (86,400 s) sync না হলে পার্থক্য সর্বোচ্চ কত?

প্রায় 1.73 s
প্রায় 34.6 s
প্রায় 3.46 s
শূন্য, কারণ দুটি সরণ কাটাকাটি হয়

(কঠিন) FLP impossibility (১৯৮৫) আর Raft-এর সম্পর্ক নিয়ে কোন বক্তব্যটি সঠিক?

Raft-এর safety সবসময় টেকে; liveness আসে timeout আর partially synchronous অনুমান থেকে
FLP দেখায় বাস্তবে consensus অসম্ভব, তাই Raft শুধু আনুমানিক সমাধান
FLP শুধু Byzantine node-এর জন্য, crash-এর জন্য নয়
Raft FLP ভাঙে, কারণ এটি majority ব্যবহার করে

(মাঝারি) Lamport clock-এ P2-এর মান 1. P2 একটি local ঘটনা ঘটাল, তারপর L = 4 লেখা একটি বার্তা পেল, তারপর একটি বার্তা পাঠাল। পাঠানো বার্তায় কোন মান যাবে?

(মাঝারি) তিন process-এর vector clock-এ ঘটনা x = [3,1,2] আর y = [3,2,2]. সম্পর্ক কী?

x আর y concurrent
x, y-র আগে ঘটেছে (x → y)
y, x-এর আগে ঘটেছে (y → x)
একই ঘটনা

(মাঝারি) NTP-র একটি আদান-প্রদানে (ms) t1 = 100, t2 = 180, t3 = 182, t4 = 142; t1, t4 client-এর ঘড়িতে, t2, t3 সার্ভারের ঘড়িতে। Offset আর round-trip delay কত?

Offset 80 ms, delay 42 ms
Offset 60 ms, delay 42 ms
Offset 60 ms, delay 40 ms
Offset 40 ms, delay 40 ms

(সহজ) CAP theorem-এর “C” বলতে কী বোঝায়?

ACID-এর C — অ্যাপের নিয়ম (যেমন ব্যালান্স ঋণাত্মক নয়) রক্ষা
Eventual consistency — শেষ পর্যন্ত সব কপি মিলবে
Durability — commit হলে ডেটা হারায় না
Linearizability — সব কপি মিলে একটি কপির মতো আচরণ, বাস্তব সময় মেনে

(মাঝারি) CAP নিয়ে কোন বক্তব্যটি সঠিক?

Partition না থাকলে CAP কোনো বাছাই চাপায় না; তখনকার দ্বন্দ্ব latency বনাম consistency
তিনটির যেকোনো দুটি নকশায় বেছে নেওয়া যায় — যেমন CA
AP সিস্টেম কখনো consistent পড়া দেয় না
CAP-এর availability মানে 99.99% uptime

(মাঝারি) একটি consensus-ভিত্তিক store-এ partition হলে সংখ্যালঘু দিক লেখা থামায়, আর স্বাভাবিক সময়েও প্রতিটি লেখায় majority-র ack লাগে। PACELC অনুযায়ী এটি কোন শ্রেণির?

PC/EC
PA/EL
PA/EC
PC/EL

(কঠিন) Register-এর শুরুর মান 0. A লিখলেন 1, সময় [0, 10] ms; B পড়ে পেলেন 0, সময় [2, 4]; C পড়ে পেলেন 1, সময় [6, 8]. এই history কোনটি?

Linearizable নয়, কারণ লেখা শুরুর পরে B 0 পেলেন
Linearizable, আর তাই sequentially consistent-ও
Sequentially consistent, কিন্তু linearizable নয়
দুটি model-এর একটিও নয়, কারণ B আর C ভিন্ন মান দেখেছেন

(মাঝারি) N = 5 replica-র leaderless store-এ কোন (W, R) পড়া-লেখার overlap নিশ্চিত করে, আর লেখা ও পড়া দুটিই ২টি replica বিকলেও চালায়?

W = 2, R = 3
W = 4, R = 2
W = 5, R = 1
W = 3, R = 3

(কঠিন) N = 3, W = 2, R = 2-এর leaderless store নিয়ে কোন দাবিটি ভুল?

একটি লেখা চলাকালীন এক পাঠক নতুন আর পরের পাঠক পুরোনো মান পেতে পারেন
R + W > N, তাই সিস্টেমটি linearizable, আর “না থাকলে তবেই লেখা” নিরাপদ
Sloppy quorum-এ hint পৌঁছানোর আগে পড়ায় নতুন মানের নিশ্চয়তা নেই
Concurrent দুটি লেখায় LWW একটিকে নিঃশব্দে ফেলে দিতে পারে

(মাঝারি) N = 3; প্রতিটি replica স্বাধীনভাবে ২০% অনুরোধে ধীর। লেখা সবচেয়ে দ্রুত W টি ack-এর অপেক্ষা করে। W = 2 হলে একটি লেখা ধীর হওয়ার সম্ভাবনা কত?

প্রায় 48.8%
20%
4%
প্রায় 10.4%

(মাঝারি) একটি key-এর দুটি ডেটা সেন্টারে ৩টি করে কপি (মোট RF 6). QUORUM-এ কয়টি ack লাগে, আর LOCAL_QUORUM-এ কয়টি?

QUORUM 2, LOCAL_QUORUM 2
QUORUM 4, LOCAL_QUORUM 2
QUORUM 3, LOCAL_QUORUM 2
QUORUM 6, LOCAL_QUORUM 3

(সহজ) একটি ৫-node Raft cluster-কে ৬-node করা হলো। এখন একসাথে কয়টি node crash সহ্য করবে?

৩টি, কারণ ৬-এর অর্ধেক
১টি, কারণ জোড় সংখ্যায় tie হয়
২টি — majority এখন ৪, আগের মতোই ২টি সহ্য
৫টি, যতক্ষণ একজন leader থাকে

(কঠিন) ৭-node Raft cluster-এ leader থেকে ছয় follower-এর RTT 1, 3, 4, 12, 40, 90 ms. fsync বাদে একটি commit-এ network-এর সময় মোটামুটি কত?

4 ms
3 ms
12 ms
25 ms

(মাঝারি) Raft-এ candidate C-এর শেষ entry: index ১০, term ৪. ভোটদাতা V-এর শেষ entry: index ১২, term ৪; V এই term-এ কাউকে ভোট দেয়নি। V কী করবে?

ভোট দেবে, কারণ term সমান
ভোট দেবে না — শেষ term সমান, কিন্তু V-এর log বেশি লম্বা, তাই C up-to-date নয়
ভোট দেবে, কারণ V এই term-এ এখনো ভোট দেয়নি
নিজেই leader হয়ে যাবে

(সহজ) একজন Raft leader একটি বার্তায় নিজের term-এর চেয়ে বড় term দেখল। সে কী করে?

নিজের term বসিয়ে বার্তাটি প্রত্যাখ্যান করে আর leader থাকে
Term আপডেট করে follower হয়ে যায়
নতুন নির্বাচন শুরু করে
Cluster বন্ধ করে দেয়

(সহজ) একটি Raft cluster-এ leader আর follower-দের মধ্যে RTT প্রায় 20 ms, অথচ election timeout বসানো হলো 10 ms. কী হবে?

দ্রুত failover, কোনো সমস্যা নেই
Commit দ্রুত হবে
বারবার অকারণ নির্বাচন — leader টেকে না
Split vote আর কখনো হবে না

(সহজ) কোন কাজে lock শুধু efficiency-র জন্য নয়, correctness-এর জন্য — অর্থাৎ consensus-ভিত্তিক lock আর fencing দরকার?

জনপ্রিয় পাতার cache একজনই আবার বানাবে
রাতের রিপোর্ট একবারই বানানো
একটি shared ledger ফাইলে একজনই লিখবে
একটি নোটিফিকেশন ইমেইল একবার পাঠানো

(কঠিন) Lease-ভিত্তিক lock নিয়ে কোন দাবিটি ভুল?

মেয়াদ পেরোলে lock service অন্য client-কে বড় token দিয়ে lock দিতে পারে
যে storage token বোঝে না, সেখানে idempotency key বা শর্তসহ লেখা লাগে
ছোট TTL-এ crash-এর পরে দ্রুত ফেরত মেলে, কিন্তু ভুয়া মেয়াদ-শেষ বাড়ে
লেখার ঠিক আগে ধারক নিজের ঘড়িতে lease-এর মেয়াদ দেখে নিলে fencing token লাগে না

(সহজ) একটি leader lease-এর TTL 15 s, নবায়ন প্রতি 5 s-এ। Leader ঠিক পরের নবায়নের আগমুহূর্তে crash করল। নতুন leader-কে মোটামুটি কতক্ষণ অপেক্ষা করতে হবে?

প্রায় 10 s
প্রায় 5 s
প্রায় 15 s
অপেক্ষা লাগে না

(কঠিন) SWIM-এ প্রতিটি বার্তা স্বাধীনভাবে ১০% হারায়; সরাসরি ping-এ ২টি বার্তা, প্রতিটি indirect probe-এ ৪টি। k = 2 হলে জীবিত সদস্যকে ভুলে suspect করার সম্ভাবনা?

19%
প্রায় 0.69%
প্রায় 2.2%
10%

(মাঝারি) ৫ সদস্যের cluster {A, B, C} আর {D, E}-তে ভাগ হলো; gossip-ভিত্তিক membership-এ প্রতিটি দল অন্য দলকে মৃত দেখছে। একটি shard-এর লেখার মালিক নিরাপদে বাছতে কী লাগবে?

Gossip-এর তালিকায় জীবিত যে কাউকে মালিক করা
Majority quorum বা consensus — শুধু {A, B, C} বাছতে পারবে
Phi threshold বাড়ানো
Gossip fanout বাড়ানো

(সহজ) একটি Bloom filter একটি key সম্পর্কে “নেই” বলল। এর অর্থ কী?

Key-টি সম্ভবত নেই, তবে থাকতেও পারে
Hash collision হয়েছে, আবার পরীক্ষা লাগবে
Filter পূর্ণ হয়ে গেছে
Key-টি নিশ্চিতভাবে set-এ নেই

(মাঝারি) ৫ কোটি key-এর জন্য 0.1% false positive-এর Bloom filter-এ মোটামুটি কত memory লাগে? (প্রতি key-এ bit = −ln p ÷ (ln 2)²)

প্রায় 62 MB
প্রায় 719 MB
প্রায় 90 MB
প্রায় 12 MB

(কঠিন) একটি HyperLogLog-এ আপেক্ষিক standard error ১%-এর বেশি চাই না (সূত্র 1.04/√m, m = 2^p, প্রতি register ৬ bit). সবচেয়ে ছোট কোন p যথেষ্ট?

p = 10 (768 byte)
p = 12 (3 KB)
p = 16 (48 KB)
p = 14 (12 KB)

(মাঝারি) Count-min sketch-এ w = ⌈e/ε⌉ আর d = ⌈ln(1/δ)⌉. ε = 0.0005, δ = 0.001 হলে আকার কত?

w = 2000, d = 7
w = 5437, d = 3
w = 5437, d = 1000
w = 5437, d = 7

(সহজ) একটি G-Counter-এর দুই replica: A = {A:5, B:2, C:0}, B = {A:3, B:4, C:1}. Merge-এর পরে counter-এর মান কত?

(মাঝারি) সার্ভার B-এর ঘড়ি 300 ms পিছিয়ে। ব্যবহারকারী আসল সময় t = 0-তে A-তে ঠিকানা লিখলেন, তারপর t = 200 ms-এ B-তে সংশোধন করলেন। Wall-clock LWW শেষে কী রাখবে?

B-র সংশোধিত ঠিকানা, কারণ সেটি পরে লেখা
দুটিই sibling হিসেবে
একটি conflict error
A-র পুরোনো ঠিকানা — সংশোধন নিঃশব্দে হারায়

(মাঝারি) একটি OR-Set কার্টে ফোন থেকে “দুধ” মোছা হলো, আর একই সময়ে (concurrent) ল্যাপটপ থেকে “দুধ” আবার যোগ হলো। Sync-এর পরে কী দেখাবে?

দুধ আছে — নতুন যোগের tag মোছার সময় দেখা হয়নি, তাই add-wins
দুধ নেই — মোছা সবসময় জেতে
দুই replica-য় দুই রকম, চিরকাল
যে কাজের timestamp বড়, সেটি

(সহজ) কোন ডেটা CRDT দিয়ে partition-এর দুই পাশে স্বাধীনভাবে লিখতে দেওয়া নিরাপদ নয়?

যে wallet-এর ব্যালান্স কখনো ঋণাত্মক হবে না
একটি পোস্টের like-সংখ্যা
কেনাকাটার cart-এর জিনিস
একটি ভিডিওর মোট view

নিজে যাচাই করুন — quorum, Raft, ঘড়ি আর sketch-এর হিসাব

N, W, R বা false positive-এর হার বদলে নিজের প্রশ্ন মেলান:

// Distributed-systems numericals: quorum, Raft, clocks, Bloom / HLL / count-min, SWIM.
const C = (n, k) => { let r = 1; for (let i = 0; i < k; i++) r = r * (n - i) / (i + 1); return r; };
const atLeast = (n, k, q) => { let s = 0; for (let i = k; i <= n; i++) s += C(n, i) * q ** i * (1 - q) ** (n - i); return s; };
for (const [N, W, R] of [[3, 2, 2], [5, 3, 3], [5, 4, 2], [4, 2, 2]])
  console.log(`N=${N} W=${W} R=${R}: overlap ${R + W > N}, writes survive ${N - W}, reads survive ${N - R}`);
console.log("W=2 of 3, each slow 20%    :", (100 * atLeast(3, 2, 0.2)).toFixed(1) + "% slow writes");
for (const n of [5, 6, 7]) console.log(`Raft n=${n}: majority ${Math.floor(n / 2) + 1}, tolerates ${Math.floor((n - 1) / 2)}`);
console.log("Clock drift +-20 ppm, 1 day:", (40e-6 * 86400).toFixed(2), "s apart");
const [t1, t2, t3, t4] = [100, 180, 182, 142];
console.log("NTP offset, delay          :", ((t2 - t1) + (t3 - t4)) / 2, "ms,", (t4 - t1) - (t3 - t2), "ms");
const bpk = -Math.log(0.001) / Math.LN2 ** 2;
console.log("Bloom 5e7 keys at 0.1%     :", bpk.toFixed(2), "bits/key,", (5e7 * bpk / 8e6).toFixed(1), "MB, k =", Math.round(bpk * Math.LN2));
for (const b of [12, 14]) console.log(`HLL p=${b}: error ${(104 / Math.sqrt(2 ** b)).toFixed(2)}%, ${2 ** b * 6 / 8 / 1024} KB`);
console.log("Count-min eps 5e-4, del 1e-3:", "w =", Math.ceil(Math.E / 0.0005), " d =", Math.ceil(Math.log(1 / 0.001)));
const direct = 1 - 0.9 ** 2, viaOne = 1 - 0.9 ** 4;
console.log("SWIM false suspicion k=0, 2:", (100 * direct).toFixed(1) + "%,", (100 * direct * viaOne ** 2).toFixed(2) + "%");

আউটপুট:

N=3 W=2 R=2: overlap true, writes survive 1, reads survive 1
N=5 W=3 R=3: overlap true, writes survive 2, reads survive 2
N=5 W=4 R=2: overlap true, writes survive 1, reads survive 3
N=4 W=2 R=2: overlap false, writes survive 2, reads survive 2
W=2 of 3, each slow 20%    : 10.4% slow writes
Raft n=5: majority 3, tolerates 2
Raft n=6: majority 4, tolerates 2
Raft n=7: majority 4, tolerates 3
Clock drift +-20 ppm, 1 day: 3.46 s apart
NTP offset, delay          : 60 ms, 40 ms
Bloom 5e7 keys at 0.1%     : 14.38 bits/key, 89.9 MB, k = 10
HLL p=12: error 1.63%, 3 KB
HLL p=14: error 0.81%, 12 KB
Count-min eps 5e-4, del 1e-3: w = 5437  d = 7
SWIM false suspicion k=0, 2: 19.0%, 2.25%

N = 4, W = 2, R = 2-এ overlap নেই; N = 5-এ (3, 3) দুই দিকেই দুটি বিকলতা সয়। Raft-এ ৬টি node-এর সহনশীলতা ৫টির সমান। তারপর ঘড়ি, NTP, Bloom filter-এর প্রায় ৯০ MB, HyperLogLog-এ p = 14, count-min আর SWIM-এ indirect probe-এর জোর (১৯% থেকে প্রায় ২.২%).

৯ · মডিউল ৮ — Architecture, reliability আর operations (২৪টি প্রশ্ন)

নকশা থেকে চালানো: সেবা ভাঙা, ব্যর্থতা আটকানো, rate limit, মাপা, বিপর্যয়ে ফেরা, সুরক্ষা আর release. ফাঁদ চেনা: retry আর availability-র গুণফল, error budget-এর মিনিট আর burn rate, MB/s বনাম Mbps; আর জোড়া-ধারণা — RPO বনাম RTO, 429 বনাম 503.

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ৪৭–৫৩

পর্ব ৪৭ · Monolith বনাম microservices — সেবার সীমানা, distributed monolith, composite availability, service discovery
পর্ব ৪৮ · Resilience pattern — timeout-এর সীমা, retry-র গুণফল, backoff + jitter, circuit breaker, bulkhead, probe
পর্ব ৪৯ · Rate limiting — token bucket-এর b + r·T, fixed window-এর সীমানা, sliding window counter, distributed counter
পর্ব ৫০ · Observability — percentile-এর গড় হয় না, cardinality, SLO, error budget আর burn-rate alert
পর্ব ৫১ · Failover আর disaster recovery — RPO-RTO, backup বনাম replication, restore-এর সময়, DNS TTL, DR কৌশল
পর্ব ৫২ · নকশায় নিরাপত্তা — password hashing, BOLA, OAuth 2.0 + PKCE, envelope encryption
পর্ব ৫৩ · Deployment আর release — rolling update-এর সীমা, blue-green বনাম canary, feature flag, expand/contract

(মাঝারি) একটি অনুরোধে ১২টি সেবাকে পরপর ডাকতে হয়, প্রতিটি স্বাধীনভাবে 99.95% সচল। পুরো অনুরোধের availability মোটামুটি কত?

99.95%
প্রায় 94%
প্রায় 99.40%
প্রায় 100%

(সহজ) কোনটি “distributed monolith”-এর সবচেয়ে স্পষ্ট চিহ্ন?

প্রতিটি সেবার নিজের database আছে
কয়েকটি সেবা একই টেবিলে লেখে, আর একসাথে deploy করতে হয়
সেবাগুলো async event দিয়ে খবর জানায়
একটি দল একটি সেবার মালিক

(সহজ) দুটি ছোট দল, নতুন পণ্য, domain-এর সীমানা বদলাচ্ছে, CI/CD কাঁচা। কোন শুরু যুক্তিসংগত?

শুরুতেই ২০টি microservice আর mesh
প্রতিটি টেবিলের জন্য একটি সেবা
এক সেবা, সব module সবার টেবিলে লেখে
Modular monolith — এক deploy, ভেতরে শক্ত module-সীমানা

(মাঝারি) Client → gateway → service → helper → database. চারটি caller-এর প্রত্যেকে নিচের স্তরকে মোট ২ বার চেষ্টা করে। Database পুরো বিকল হলে একটি অনুরোধে database সর্বোচ্চ কত চেষ্টা পায়?

৮টি
১৬টি
২টি
৫টি

(মাঝারি) একটি dependency-র ভাগে ৬০টি thread, আর প্রতি সেকেন্ডে 300টি call আসে। Dependency পুরো ঝুলে গেলেও ভাগ যেন না ভরে — timeout সর্বোচ্চ কত?

200 ms
5 s
20 ms
30 s, নিরাপদ থাকতে

(কঠিন) Full jitter backoff: অপেক্ষা = rand(0, min(cap, base × 2^k)), base = 0.5 s, cap = 30 s. k = 7-এ অপেক্ষার পরিসর আর গড় কত?

০ থেকে ৩০ সেকেন্ড, গড় ১৫
০ থেকে ৬৪ সেকেন্ড, গড় ৩২
ঠিক ৩০ সেকেন্ড
১৫ থেকে ৩০ সেকেন্ড

(সহজ) Circuit breaker half-open অবস্থায় কী করে?

সব call আটকে fallback দেয়
সব call যেতে দেয় আর ব্যর্থতা গোনে
Dependency-কে restart করে
অল্প কয়েকটি probe পাঠায়; সফলে closed, ব্যর্থে আবার open

(সহজ) Token bucket-এ r = 5 token/s আর b = 20, অনেকক্ষণ কোনো অনুরোধ আসেনি। যেকোনো ১০ সেকেন্ডে সর্বোচ্চ কত অনুরোধ ছাড়া পাবে?

৭০
৫০
২০
২০০

(কঠিন) মিনিটে ১০০-র sliding window counter: আগের মিনিটে ৯০টি, এখনকার মিনিটে এ পর্যন্ত ৪৫টি, মিনিটের ১৫ সেকেন্ড পেরিয়েছে। নতুন অনুরোধের কী হবে?

ছাড়া পাবে, অনুমান ৪৫
ছাড়া পাবে, অনুমান ৬৭.৫
ফেরত (429), কারণ অনুমান ১১২.৫
ফেরত, অনুমান ১৩৫

(মাঝারি) চারটি API instance প্রত্যেকে নিজের memory-তে “মিনিটে ১০০” গোনে, load balancer পালা করে (round robin) অনুরোধ পাঠায়। একজন ব্যবহারকারী মিনিটে সর্বোচ্চ কত অনুরোধ পার করাতে পারেন?

প্রায় ৪০০
১০০
২৫
২০০

(সহজ) একজন ক্লায়েন্ট নিজের ভাগ ছাড়ালে সার্ভার কোন status দেয়, আর সার্ভার নিজে উপচে পড়লে কোনটি?

দুটিতেই 503
ভাগ ছাড়ালে 403, উপচালে 500
ভাগ ছাড়ালে 429, সার্ভার উপচালে 503
ভাগ ছাড়ালে 503, উপচালে 429

(মাঝারি) ২৮ দিনের জানালায় SLO 99.99%. সম্পূর্ণ বিভ্রাট ধরলে error budget কত মিনিট?

৪.৩২ মিনিট
৪০.৩২ মিনিট
০ মিনিট
প্রায় ৪.০৩ মিনিট

(কঠিন) ৩০ দিনের SLO 99.9%; এখন error ratio স্থিরভাবে 0.6%. Burn rate কত, আর এই হারে বাজেট কতদিনে শেষ?

০.৬; ৫০ দিনে
৬; ৬ দিনে
৬; ৫ দিনে
৬০; ১২ ঘণ্টায়

(সহজ) দশটি সার্ভারের p99-এর গড় নিয়ে পুরো সেবার p99 বলা হলো। কোন কথাটি সঠিক মূল্যায়ন?

ঠিক আছে, যদি সব সার্ভার সমান ট্রাফিক পায়
ভুল — bucket যোগ করে তারপর p99 হিসাব করতে হয়
গড় সবসময় আসল p99-এর বেশি
Median নিলে ঠিক হবে

(সহজ) একটি metric-এ label route (১০টি মান), status (৪টি), pod (৩০টি)। সবচেয়ে খারাপ ক্ষেত্রে কতগুলো time series?

৪৪টি
১,২০০টি
১২০টি
৩০টি

(সহজ) RPO আর RTO-র পার্থক্য কোনটি?

RPO = সেবা ফিরতে সময়; RTO = ডেটা হারানো
দুটিই availability-র শতাংশ
RPO backup-এর আকার, RTO network-এর গতি
RPO = কত সময়ের ডেটা হারানো চলে; RTO = কতক্ষণ সেবা বন্ধ চলে

(মাঝারি) 3 TB backup restore করতে হবে, কার্যকর গতি 250 MB/s (megabyte প্রতি সেকেন্ড; 1 TB = 10⁶ MB ধরুন)। শুধু ডেটা নামাতে মোটামুটি কত সময়?

প্রায় ২৬.৭ ঘণ্টা
প্রায় ৩.৩ ঘণ্টা
প্রায় ২০০ ঘণ্টা
প্রায় ১২ মিনিট

(মাঝারি) Database-এর দুটি synchronous replica; একটি ভুল script সব ঠিকানা মুছে দিল। কোনটি সত্য?

Synchronous replica থেকে ডেটা ফেরানো যাবে
Replica-তেও মোছা পৌঁছে গেছে; ফেরাতে লাগবে point-in-time backup
Failover করলেই ডেটা ফিরবে
RPO শূন্য, তাই কোনো ক্ষতি নেই

(সহজ) ব্যবহারকারী A বৈধ token দিয়ে GET /orders/9001 চাইলেন, উত্তরে এলো B-এর অর্ডার। আসল প্রতিকার কোনটি?

Token-এর মেয়াদ কমানো
Gateway-তে আরও কড়া token যাচাই
Orders সেবায় অর্ডারের owner আর token-এর ব্যবহারকারী মেলানো
অর্ডারের id এলোমেলো করা

(মাঝারি) OAuth 2.0-এর authorization code flow-তে PKCE মূলত কোন ঝুঁকি কমায়?

Password দুর্বল হওয়া
Access token-এর মেয়াদ বেশি হওয়া
পথে চুরি যাওয়া authorization code দিয়ে অন্য কারও token নেওয়া
Server-এর TLS না থাকা

(কঠিন) Envelope encryption-এ ৫০ লাখ object, প্রতিটির মোড়া DEK 48 byte. KEK বদলে সব DEK আবার মোড়ালে মোটামুটি কত byte ছুঁতে হবে?

প্রায় 240 MB
পুরো ডেটার সমান
প্রায় 240 KB
প্রায় 2.4 GB

(কঠিন) Kubernetes Deployment-এ replicas = 6, maxSurge = 25%, maxUnavailable = 25%. Rolling update-এ সর্বোচ্চ কত Pod থাকবে, আর কমপক্ষে কতটি প্রস্তুত?

সর্বোচ্চ ৭, কমপক্ষে ৫
সর্বোচ্চ ৮, কমপক্ষে ৪
সর্বোচ্চ ৬, কমপক্ষে ৬
সর্বোচ্চ ৮, কমপক্ষে ৫

(মাঝারি) নতুন সংস্করণে বিরল bug থাকতে পারে; ক্ষতি অল্পে রেখে মেপে এগোতে চান। কোন কৌশল?

Canary — অল্প traffic নতুনে, metric দেখে ধাপে ধাপে বাড়ানো
Blue-green — এক ধাপে সবাইকে নতুনে
Recreate — সব পুরোনো বন্ধ, তারপর নতুন
Shadow — traffic-এর কপি, উত্তর ফেলে দেওয়া

(মাঝারি) চলমান সেবায় downtime ছাড়া users.phone কলামের নাম mobile করতে হবে। কোন ক্রমটি সঠিক?

সরাসরি RENAME, তারপর নতুন কোড deploy
নতুন কলাম যোগ → পড়া বদল → backfill
পুরোনো কলাম মোছা → নতুন কলাম যোগ
নতুন কলাম যোগ → দুটিতে লেখা → backfill → পড়া বদল → পুরোনো কলাম মোছা

নিজে যাচাই করুন — retry, rate limit, SLO আর rollout-এর হিসাব

// Reliability and operations numericals: chains, retries, backoff, rate limits, SLOs, restore, rollout.
console.log("12 services in series, 99.95%  :", (100 * 0.9995 ** 12).toFixed(2) + "%");
console.log("4 layers x 2 attempts each     :", 2 ** 4, "attempts at the database");
console.log("Timeout, 60 threads at 300/s   :", Math.round(60 / 300 * 1000), "ms");
const cap = k => Math.min(30, 0.5 * 2 ** k);       // full jitter: rand(0, cap(k))
console.log("Full jitter k = 7              : 0 ..", cap(7), "s, mean", cap(7) / 2, "s");
console.log("Token bucket r=5, b=20, 10 s   :", 20 + 5 * 10, "requests");
const est = 90 * (45 / 60) + 45;                   // previous x overlap + current
console.log("Sliding window counter         :", est, est >= 100 ? "-> 429" : "-> allow");
console.log("Error budget 99.99%, 28 days   :", (28 * 24 * 60 * 1e-4).toFixed(3), "min");
const burn = 0.6 / 0.1;                            // error ratio % / budget %
console.log("Burn rate, days to exhaust 30 d:", burn.toFixed(1), (30 / burn).toFixed(1));
console.log("Series 10 routes x 4 x 30 pods :", 10 * 4 * 30);
console.log("Restore 3 TB at 250 MB/s       :", (3e6 / 250 / 3600).toFixed(2), "h");
const r = 6, surge = Math.ceil(r * 0.25), unav = Math.floor(r * 0.25);
console.log("Rolling 6 pods, 25% / 25%      : max", r + surge, "pods, min", r - unav, "ready");

আউটপুট:

12 services in series, 99.95%  : 99.40%
4 layers x 2 attempts each     : 16 attempts at the database
Timeout, 60 threads at 300/s   : 200 ms
Full jitter k = 7              : 0 .. 30 s, mean 15 s
Token bucket r=5, b=20, 10 s   : 70 requests
Sliding window counter         : 112.5 -> 429
Error budget 99.99%, 28 days   : 4.032 min
Burn rate, days to exhaust 30 d: 6.0 5.0
Series 10 routes x 4 x 30 pods : 1200
Restore 3 TB at 250 MB/s       : 3.33 h
Rolling 6 pods, 25% / 25%      : max 8 pods, min 5 ready

১২টি সেবার শিকলে মাত্র ৯৯.৪০%, চার স্তরের retry-তে ১৬টি চেষ্টা, আর Little-এর সূত্রে timeout ২০০ ms. তারপর token bucket, sliding window (১১২.৫, তাই 429), ২৮ দিনের error budget ৪.০৩২ মিনিট আর burn rate ৬ — বাজেট ৫ দিনে শেষ।

১০ · মডিউল ৯ — Case study (২৪টি প্রশ্ন)

আটটি case study-র প্রশ্ন — প্রতিটিতে একটি কাল্পনিক সেবার সংখ্যা বা পরিস্থিতি। বেশি ভুল হয় random code-এর collision উপেক্ষায় (birthday-র অঙ্ক), fan-out on write-এর খরচ ভুল মাপায়, আর client-এর ঘড়ি দিয়ে বার্তার ক্রম ঠিক করায়। হিসাবে ১ দিন = 86,400 সেকেন্ড।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ৫৪–৬১

পর্ব ৫৪ · URL shortener — base62 code-এর দৈর্ঘ্য, birthday bound, 301 বনাম 302, click analytics
পর্ব ৫৫ · Chat আর messaging — client id আর dedup, কথোপকথনপ্রতি seq, ডিভাইসের cursor, gateway আর presence
পর্ব ৫৬ · News feed — push, pull আর hybrid fan-out, ID-ভিত্তিক timeline, rebuild, pull-এর লেজ
পর্ব ৫৭ · Notification system — worker-এর হিসাব, SMS-এর টুকরো, অগ্রাধিকারের lane, provider বদল
পর্ব ৫৮ · Ride-sharing — অবস্থান-লেখার হার, geohash, soft state আর matching
পর্ব ৫৯ · Video streaming — resumable upload, transcoding ladder, segment আর adaptive bitrate
পর্ব ৬০ · Ticket booking আর payment — শর্তসহ লেখা, optimistic concurrency, idempotency, double-entry ledger
পর্ব ৬১ · ক্যাপস্টোন KV store — consistent hashing, N/W/R, vector clock, hinted handoff, Merkle tree

(মাঝারি) Counter-ভিত্তিক base62 code-এ ১০০ কোটি (10⁹) link-এর জন্য অন্তত কয়টি অক্ষর লাগে?

৫টি
৭টি
৬টি
১০টি

(কঠিন) ৭ অক্ষরের random base62 code (M = 62⁷ ≈ 3.52 × 10¹²), ১০ কোটি (10⁸) link, যাচাই ছাড়া। গড়ে কতটি collision?

০টির মতো — জায়গা বিশাল
১,৪২০টির মতো
১৪টির মতো
২,৮৪০টির মতো

(সহজ) Redirect 301 (স্থায়ী) হলে একই browser-এ একই link দ্বিতীয়বার চাপলে সাধারণত কী হয়?

প্রতিবার সার্ভারে এসে click গোনা হয়
Browser error দেখায় — 301 একবারই চলে
সার্ভার নতুন code বানায়
Browser সরাসরি গন্তব্যে যায়; সার্ভার click দেখে না

(মাঝারি) ভাইরাল link-এ সেকেন্ডে ১০ হাজার click. Redirect দ্রুত রেখে click গোনার উপযুক্ত নকশা কোনটি?

প্রতি redirect-এর আগে একই সারিতে counter বাড়ানো
Redirect আর গণনা একটি distributed transaction-এ
Redirect-এর পথে শুধু event পাঠানো; গণনা আলাদা stream-এ
301 দিয়ে browser-এ cache করানো

(মাঝারি) Chat অ্যাপ বার্তা সাজায় ফোনের timestamp দিয়ে; এক সদস্যের ঘড়ি ৫ মিনিট পিছিয়ে। কী ঘটবে, প্রতিকার কী?

উত্তর মূল বার্তার আগে দেখায়; প্রতিকার কথোপকথনপ্রতি server-এর seq
কিছুই না — NTP সব ঘড়ি নিখুঁত রাখে
বার্তা হারাবে; প্রতিকার দুবার পাঠানো
ক্রম ভুল; প্রতিকার একটি global auto-increment

(কঠিন) Chat server টেকসই লেখার আগেই প্রেরককে “sent” ack পাঠাল, তারপর crash. ফল কী?

প্রাপক বার্তা দুবার পাবেন
কিছুই হারাবে না — WebSocket নিশ্চয়তা দেয়
“Sent” দেখায়, অথচ বার্তা চিরতরে হারানো
ফোন একই client id-তে আবার পাঠাবে

(সহজ) ৫০০ সদস্যের group-এ প্রত্যেকের inbox-কপির বদলে একটি conversation log আর ডিভাইসপ্রতি cursor রাখার প্রধান লাভ?

Push notification আর লাগে না
বার্তা একবার লেখা হয়, সবাই একই ক্রমে পড়েন
End-to-end encryption অপ্রয়োজনীয়
Presence-এর খরচ শূন্য

(মাঝারি) Peak-এ ৯০ লাখ WebSocket সংযোগ, gateway-প্রতি সর্বোচ্চ 60,000; তিন zone-এর একটি হারালেও সব সংযোগ ধরতে হবে। কয়টি gateway?

১৫০টি
৪৫০টি
২২৫টি
৩০০টি

(মাঝারি) Push feed: দিনে ৫০ লাখ পোস্ট, গড়ে ২০০ follower, peak = গড় × 3, ১ দিন = 86,400 s. Peak-এ timeline-লেখা/সেকেন্ড?

৩৪,৭০০-র মতো
১১,৬০০-র মতো
১৭৪-এর মতো
৩,৪৭,০০০-এর মতো

(সহজ) ১ কোটি ব্যবহারকারীর timeline-এ ৫০০টি করে 8-byte post ID (overhead বাদ)। মোট memory?

4 GB
400 GB
40 TB
40 GB

(মাঝারি) Push feed ৩০ দিন অনুপস্থিতদের timeline মুছে fan-out থেকে বাদ দেয়। তেমন একজন ফিরলে কী হয়?

Followee-দের author timeline থেকে k-way merge-এ নতুন করে বানানো হয়
Feed চিরতরে ফাঁকা থাকে
পুরোনো সব পোস্ট আবার fan-out হয়
TTL বাড়িয়ে পুরোনো timeline ফেরানো হয়

(মাঝারি) Timeline cache-এর একটি node মরে লাখো timeline হারাল। সবচেয়ে নিরাপদ প্রতিক্রিয়া?

সব timeline একসাথে rebuild
Cache বাদে সব feed post store থেকে
বাকি node-এর TTL বাড়ানো
Replica-তে failover, সীমিত হারে rebuild, ততক্ষণ সরল feed

(মাঝারি) ৫০ লাখ push ১০ মিনিটে; worker-প্রতি 500/s, utilisation 70%-এর বেশি নয়। অন্য চাপ বাদে কয়টি worker?

১৭টি
২৪টি
১,০০০টি
১২টি

(সহজ) ১৪০ অক্ষরের বাংলা SMS: UCS-2-এ এক টুকরোয় ৭০, জোড়া বার্তায় টুকরোপ্রতি ৬৭ অক্ষর। কয় টুকরো?

২টি
১টি
৩টি
৪টি

(মাঝারি) বড় প্রচারের সময় OTP SMS দেরিতে পৌঁছায়। সবচেয়ে কার্যকর পরিবর্তন?

OTP-র আলাদা অগ্রাধিকারের lane (bulkhead)
একই FIFO-তে worker দ্বিগুণ
OTP push-এ, SMS বন্ধ
Retry-র সংখ্যা বাড়ানো

(মাঝারি) Geohash-এ একটি অক্ষর বাড়ালে (৬ থেকে ৭) cell-এর ক্ষেত্রফল মোটামুটি কী হয়?

অর্ধেক
৬২ ভাগের এক ভাগ
১০ ভাগের এক ভাগ
৩২ ভাগের এক ভাগ

(মাঝারি) চালকের সর্বশেষ অবস্থান রাখতে কোন নকশা মানানসই?

প্রতি ping-এ relational DB-তে ACID UPDATE
সব ping একটি log-এ, প্রতি অনুরোধে পুরো scan
Cell ধরে ভাগ করা in-memory store, নতুন মানে ঢাকা, TTL-সহ
Object storage-এ চালকপ্রতি ফাইল

(মাঝারি) Ladder 0.4, 0.8, 1.4, 2.8, 5.0 Mbit/s. এক ঘণ্টার ভিডিওর সব মানের storage (replication বাদ)?

4.68 GB
37.4 GB
2.25 GB
4.68 MB

(সহজ) 2 GB ভিডিও 8 MB টুকরোয় resumable upload; ১৫০তম টুকরোর পরে সংযোগ কাটল। এরপর কী হয়?

পুরো ফাইল শুরু থেকে আবার
পৌঁছানো টুকরো জেনে বাকিগুলো পাঠানো হয়
আধা ফাইলই transcode হয়ে প্রকাশ
CDN বাকি অংশ পূরণ করে

(কঠিন) পুরো show-এর একটিই version রেখে optimistic concurrency; হাজারো ক্রেতা আলাদা সিট চান। কী ঘটবে?

একই সিট দুবার বিক্রি
সমস্যা নেই — optimistic পদ্ধতি আটকায় না
Database-এ deadlock
আলাদা সিটেও version-সংঘাত — বেশিরভাগ লেখা ব্যর্থ, retry-এর ঢল

(মাঝারি) একটি bug জোড়া লাইন ছাড়া একটি account-এর balance সরাসরি বদলাল। Double-entry ledger-এ কীভাবে ধরা পড়ে?

ধরা যায় না
লাইনের যোগফল শূন্য থাকে না — trial balance মেলে না
শুধু গ্রাহকের অভিযোগে
Gateway নিজে বাতিল করে

(মাঝারি) Virtual node-সহ ring-এ N = 3. একটি key-এর preference list বানাতে ঘড়ির কাঁটার দিকে কোন তিনটি নেওয়া হয়?

পরপর তিনটি virtual node, যে physical node-এরই হোক
প্রথম তিনটি আলাদা physical node — একই node-এর বাড়তি virtual node বাদ
Ring-এর সবচেয়ে কম ভার বহনকারী তিনটি node
এলোমেলো তিনটি node, প্রতিটি লেখায় নতুন করে

(মাঝারি) একই key-এর দুটি সংস্করণের vector clock {A:3, B:1} আর {A:2, B:2}. Store কী করবে?

{A:3, B:1} — যোগফল বেশি
{A:2, B:2} — পরে এসেছে
Error দিয়ে বাতিল
দুটিই sibling — কেউ কাউকে ঢাকে না

(মাঝারি) Leaderless KV store-এ Merkle tree দিয়ে anti-entropy চালানোর মূল লাভ কী?

Hash মিলিয়ে শুধু অমিল key-পরিসর খুঁজে পাঠানো
নির্দিষ্ট সময় পরপর সব key পাঠানো
Leader বাছাই
কোন SSTable-এ key নেই, ডিস্ক না ছুঁয়ে জানা

AI-এর যুগে — AI দিয়ে আরও MCQ বানান, কিন্তু উত্তর নিজে যাচাই করুন

এই পাতা শেষ হলে আরও অনুশীলন চাইবেন, আর AI চ্যাটবট মুহূর্তে শত শত MCQ বানাতে পারে। কিন্তু system design-এর MCQ-তে AI প্রায়ই ভুল অপশনকে “সঠিক” বলে, বা একই প্রশ্নে দুটি সঠিক অপশন রাখে। ভুল হয় ঠিক এই পাতার ফাঁদগুলোতে — “CA”, quorum = strong consistency, ACID আর CAP মেশানো, “exactly-once”, হিসাবের ভুল, বানানো product limit; আর সব প্রশ্নের উত্তর প্রায়ই একই: “Kafka, Redis আর microservices যোগ করুন”।

AI-এর প্রচলিত ভুল	উদাহরণ	কীভাবে ধরবেন
ভুল হিসাব, নিশ্চিত সুরে	“99.9% মানে মাসে ৪ ঘণ্টা downtime”	নিজে খাতায় করুন, বা এই পাতার checker-এ সংখ্যা বসান
রীতি না বলা	দিন 86,400 s না 10⁵, KB না KiB — চুপ	প্রশ্নে রীতি লেখা চান; দুই রীতিতে উত্তর বদলায় কি না দেখুন
সংজ্ঞা মেশানো	ACID-এর C আর CAP-এর C এক; quorum = linearizable	সংশ্লিষ্ট পর্বের সংজ্ঞার সাথে শব্দে শব্দে মেলান
দুটি সঠিক অপশন	“কোনটি idempotent?” — PUT আর DELETE দুটিই	প্রতিটি অপশনের পাশে স বা ভু লিখে দেখুন ঠিক একটি টেকে কি না
বানানো তথ্য	কোনো product-এর সীমা বা দাম; “অমুক পরীক্ষায় এসেছিল”	Official documentation দেখুন; উৎস দেখাতে না পারলে দাবি বাদ
ব্যর্থতা বাদ	“সঠিক নকশা” অপশনে failure mode বা দাম নেই	প্রতিটি অপশনে জিজ্ঞেস করুন — node মরলে, network ভাঙলে কী হয়

নিচের প্রম্পটটি AI-কে প্রশ্ন বানাতে বলে, সাথে এমন তথ্যও চায়, যা দিয়ে আপনি উত্তর যাচাই করতে পারবেন:

আমি system design-এর MCQ পরীক্ষার প্রস্তুতি নিচ্ছি (বিশ্ববিদ্যালয়, চাকরির লিখিত পরীক্ষা আর ইন্টারভিউ)। বিষয়: [যেমন: CAP ও consistency model / quorum ও Raft / cache-aside ও invalidation / delivery semantics ও idempotency / availability ও SLO-র হিসাব] কঠিনতা: [সহজ / মাঝারি / কঠিন] ১০টি MCQ বানাও। প্রতিটির জন্য: ১. প্রশ্ন আর ঠিক ৪টি অপশন; শুধু একটি সঠিক। দরকারি সব সংখ্যা প্রশ্নেই থাকবে। ২. যে রীতি ধরছ, প্রশ্নেই লেখো (১ দিন কত সেকেন্ড, KB না KiB, percentile-এর পদ্ধতি, “consistency” বলতে ACID না CAP-এর অর্থ)। ৩. সঠিক উত্তর, আর প্রতিটি ভুল অপশন কোন ভুল ধারণা বা কোন হিসাবের ভুল থেকে এসেছে — এক লাইনে। ৪. numerical-এ প্রতিটি ধাপ এককসহ দেখাও; নকশার প্রশ্নে সঠিক অপশনের দাম বা failure mode-ও লেখো। ৫. কোনো product-এর সীমা বা দাম বললে official উৎস দাও, নিশ্চিত না হলে বাদ দাও; কোনো প্রশ্নকে কোনো নির্দিষ্ট পরীক্ষার আসল প্রশ্ন বলে দাবি করবে না।

যাচাইয়ের চেকলিস্ট

প্রতিটি numerical নিজে খাতায় বা ছোট script-এ করেছি; উত্তরের একক অপশনের এককের সাথে মিলেছে
চারটি অপশনের মধ্যে ঠিক একটি সত্য — দুটি সত্য হয়ে যাওয়া প্রশ্ন ঠিক করেছি
সংজ্ঞাগুলো (CAP, isolation level, delivery semantics) কোর্সের পর্বের সাথে মিলিয়েছি
নকশার প্রশ্নে failure-mode দেখেছি: node মরলে, network ভাঙলে, retry এলে সঠিক অপশনটি টেকে কি না
Product-এর সীমা বা দাম official documentation-এ দেখেছি, বা ছোট simulation বা load test-এ মেপেছি

কেন এই উত্তর ভুল? — রিভিশনের কৌশল আর সবচেয়ে বেশি ভুল হওয়া ধারণা

প্রথমটি এই প্রশ্নব্যাংক দিয়ে কীভাবে রিভিশন করবেন তা নিয়ে; বাকিগুলো এমন ধারণা, যেখানে এই পাতার প্রশ্নে সবচেয়ে বেশি ভুল হয়। আগে নিজে ভাবুন — তারপর খুলে দেখুন।

প্র ০১এতগুলো প্রশ্ন একবারে পড়ে মনে থাকে না। এই প্রশ্নব্যাংক দিয়ে কীভাবে রিভিশন করলে সবচেয়ে বেশি কাজে লাগে?

একটানা পড়ে যাওয়া — প্রশ্ন দেখা, উত্তর চাপা, এগোনো — সবচেয়ে কম কাজে লাগে। কার্যকর দুটি অভ্যাস: নিজে থেকে মনে করা (active recall) আর বিরতি দিয়ে ফেরা (spaced repetition).

এক অংশ, পুরো মনোযোগ: একবারে একটি মডিউলের অংশ নিন। চাপার আগে খাতায় নিজের উত্তর আর এক লাইনের কারণ লিখুন — “R + W = 4 > 3, কিন্তু sloppy, তাই নয়”. কারণ লিখতে না পারলে আন্দাজটিকে ভুল হিসেবেই গুনুন, ঠিক হলেও।
ভুলের খাতা: প্রতিটি ভুলের পাশে প্রশ্ন নয়, নিয়মটি লিখুন — “series availability গুণফল”. পরীক্ষায় একই নিয়ম অন্য সংখ্যায় আসবে।
সংখ্যা বদলে নতুন প্রশ্ন: N = 5-এর বদলে 7, SLO 99.9%-এর বদলে 99.95% — আগে খাতায় করুন, তারপর এই পাতার checker-এ মেলান।
পর্বে ফিরে যাওয়া: একটি অংশে তিনটির বেশি ভুল হলে তার পর্বগুলো আবার পড়ুন; ১, ৩ আর ৭ দিন পরে শুধু ভুলগুলো করুন, অপশন পড়ার আগেই উত্তর বলে।

মূল উপলব্ধি: প্রশ্ন নয়, প্রশ্নের পেছনের নিয়ম মনে রাখাই লক্ষ্য — নিজে উত্তর আর কারণ লিখুন, সংখ্যা বদলে আবার করুন, বিরতি দিয়ে ফিরে আসুন।

প্র ০২CAP নিয়ে তিনটি ভুল ব্যাখ্যা প্রায় সব distractor-এর উৎস। সেগুলো কী, আর সঠিক ব্যাখ্যা কী?

Eric Brewer ২০০০ সালে অনুমানটি দেন, আর Gilbert ও Lynch ২০০২ সালে একটি নির্দিষ্ট মডেলে তা প্রমাণ করেন। প্রমাণিত কথাটি সরু: network partition চলাকালে একটি সিস্টেম একসাথে linearizable পড়া-লেখা আর প্রতিটি সুস্থ node-এ উত্তর — দুটি দিতে পারে না।

ভুল ব্যাখ্যা ১ — “তিনটির যেকোনো দুটি বেছে নিন”। Partition নকশাকারের বাছাই নয়; তার ছেঁড়া, switch বিকল বা GC pause ঘটবেই। তাই “CA” আসলে একটি অবস্থা নয় — partition এলে হয় এক পাশ থামবে (C), নয়তো দুই পাশ চলবে আর মান ভিন্ন হবে (A).

ভুল ব্যাখ্যা ২ — CAP-এর C = ACID-এর C. ACID-এর C মানে অ্যাপের নিয়ম রক্ষা — ব্যালান্স ঋণাত্মক নয়, foreign key ভাঙে না। CAP-এর C মানে সব কপি মিলে একটি কপির মতো আচরণ, বাস্তব সময় মেনে। একটি যন্ত্রের database-এ প্রথমটি আছে, দ্বিতীয়টির প্রশ্নই ওঠে না।

ভুল ব্যাখ্যা ৩ — “AP মানে কখনো consistent নয়, আর CAP-ই একমাত্র trade-off”. AP সিস্টেম partition না থাকলে প্রায়ই সর্বশেষ মান দেয়; আর partition না থাকলেও দাম আছে — প্রতিটি লেখায় দূরের replica-র ack অপেক্ষা মানে বেশি latency. Daniel Abadi ২০১২ সালে এটিকেই PACELC নামে বলেন: Partition হলে A বনাম C, Else Latency বনাম Consistency.

মূল উপলব্ধি: CAP একটি সরু উপপাদ্য — partition-এর সময় linearizability বনাম availability; বাকি সময়ের প্রশ্ন PACELC-এর latency বনাম consistency, আর ACID-এর C একেবারে আলাদা ধারণা (পর্ব ৪০)।

প্র ০৩R + W > N হলে পড়া আর লেখার দল মেলে। তবু leaderless quorum কেন linearizable নয়?

Quorum intersection একটি সত্যিকারের উপপাদ্য: N টি replica-র যেকোনো W টি আর যেকোনো R টির দল, R + W > N হলে, অন্তত একটি replica-তে মেলে। কিন্তু উপপাদ্যটি বলে শুধু এটুকু — পড়ার দল সম্পন্ন লেখার অন্তত একটি কপি ছোঁয়। Linearizability চায় আরও বেশি: একবার কেউ নতুন মান দেখলে পরের সবাই নতুনটিই দেখবেন। ফাঁক অন্তত চারটি।

চলমান লেখা: N = 3, W = 2-এ লেখা এখন পর্যন্ত একটি replica-তে পৌঁছেছে। পাঠক A-র দল সেটি ছুঁয়ে নতুন মান পেলেন, ঠিক পরে পাঠক B-র দল অন্য দুটি ছুঁয়ে পুরোনো — সময় পেছনে গেল।
ব্যর্থ আংশিক লেখা: W পূরণ না হলেও যে replica-তে লেখা পৌঁছেছে, সেখানে রয়ে যায়; পরে read repair তাকে ছড়িয়েও দিতে পারে।
Sloppy quorum: নির্ধারিত replica বন্ধ থাকলে বাইরের node-এর ack গোনা হয়; hint পৌঁছানোর আগে overlap নিশ্চিত নয়।
একসাথে দুটি লেখা আর LWW: বড় timestamp জেতে, অন্যটি নিঃশব্দে হারায়; ঘড়ি সরে থাকলে “পরের” লেখাটিই হারাতে পারে।

তাই “এই username না থাকলে তবেই নাও”-এর মতো শর্তযুক্ত লেখা quorum দিয়ে নিরাপদ নয় — সেখানে consensus (Raft-এর মতো) লাগে। Quorum ভালো যেখানে লেখা নেওয়াই সবচেয়ে জরুরি আর conflict মেলানো যায়: cart, session, চালকের অবস্থান।

মূল উপলব্ধি: R + W > N = সম্পন্ন লেখার সাথে overlap, linearizability নয়; শর্তযুক্ত বা অনন্য লেখায় consensus বেছে নিন (পর্ব ৪১, ৪২)।

প্র ০৪“Exactly-once delivery” কেন ভুল প্রতিশ্রুতি? At-least-once আর idempotency মিলে কীভাবে কার্যত একবার হয়?

প্রেরক একটি বার্তা পাঠিয়ে ack পেলেন না। দুটি সম্ভাবনা — বার্তাটি হারিয়েছে, নাকি বার্তা পৌঁছে ack হারিয়েছে — প্রেরকের দিক থেকে হুবহু এক রকম দেখায়। আবার পাঠালে duplicate-এর ঝুঁকি (at-least-once), না পাঠালে হারানোর ঝুঁকি (at-most-once). হারাতে পারে এমন network-এ তৃতীয় পথ নেই; “ack-এর ack” নিলেও শেষ ack-টি নিয়ে একই প্রশ্ন।

তাই বাস্তব নকশা: at-least-once পাঠানো, আর গ্রহীতাকে idempotent বানানো — একই বার্তা দুবার এলেও ফল একবারের মতো। একে বলে effectively-once. উপায়: প্রতিটি বার্তার একটি অনন্য id, আর গ্রহীতার database-এ “এই id প্রক্রিয়া হয়েছে” চিহ্ন।

সূক্ষ্ম শর্তটিতেই বেশিরভাগ ভুল: চিহ্ন আর effect একই transaction-এ। আগে Redis-এ SETNX দিয়ে চিহ্ন, তারপর আলাদা database-এ টাকা যোগ — মাঝে crash হলে redelivery-তে চিহ্ন দেখে বার্তা বাদ, টাকা কখনো যোগ হয় না। উল্টো ক্রমে টাকা দুবার। দুটি একসাথে commit হলে তবেই নিরাপদ।

আর broker-এর “exactly-once” নিশ্চয়তা তার নিজের সীমানার ভেতরে — topic থেকে topic-এ লেখা। বাইরের কাজ (SMS, payment, ইমেইল) আর ack-এর মাঝে crash হলে কাজটি আবার হবে; সেখানে idempotency key বা বাইরের সেবার নিজস্ব dedup লাগে।

মূল উপলব্ধি: Delivery-র স্তরে exactly-once অসম্ভব; at-least-once + idempotent consumer, চিহ্ন আর effect একই transaction-এ — এটিই “একবার” (পর্ব ৩৪)।

প্র ০৫Cache-aside-এ লেখার পরে key delete করা হলো, তবু কেন পুরোনো মান ফিরে আসে? কোন ক্রম সবচেয়ে নিরাপদ?

Cache-aside-এ cache নিজে database চেনে না; app miss পেলে database পড়ে মানটি cache-এ বসায় (set). ঝামেলা দুটি কাজের ফাঁকে। সময়রেখা: পাঠক A miss পেয়ে database থেকে v1 পড়লেন, কিন্তু set-এর আগে থেমে গেলেন (GC pause বা ধীর network). এর মধ্যে লেখক v2 commit করে key delete করলেন। তারপর A দেরিতে v1 set করলেন। এখন cache-এ পুরোনো v1, আর delete ইতিমধ্যে হয়ে গেছে — TTL শেষ না হওয়া পর্যন্ত সবাই v1 পাবেন।

ক্রমের তুলনা: আগে cache delete, তারপর database update সবচেয়ে খারাপ — পুরো লেখার সময় জুড়ে যেকোনো পাঠক পুরোনো মান আবার বসাতে পারেন। Database update, তারপর cache-এ নতুন মান SET-এ দুই লেখকের ক্রম উল্টে গেলে পুরোনোটি শেষে বসে। প্রচলিত নিরাপদ পথ: commit, তারপর delete — জানালাটি সরু হয়, কিন্তু শূন্য নয়।

বাকি ঝুঁকি সামলানোর তিন উপায়: TTL — পুরোনো মান কতক্ষণ থাকতে পারে তার শেষ সীমা; lease বা version-চিহ্ন — miss-এ একটি টোকেন দেওয়া, আর মাঝে delete হলে পুরোনো টোকেনের set বাতিল; আর যেখানে পুরোনো মান একদমই চলে না (stock, ব্যালান্স), সেখানে cache থেকে নয়, database থেকে পড়া।

মূল উপলব্ধি: Delete পুরোনো মান ফেরা বন্ধ করে না — দেরিতে আসা set তা ফেরায়; commit-then-delete, সাথে TTL আর দরকারে lease (পর্ব ২৮, ২৯)।

প্র ০৬Raft-এর majority আর lease-এর মেয়াদ — দুটি “নিরাপদ” হিসাব কোথায় ভুল গোনা হয়?

Majority গোনা। n টি node-এর Raft cluster-এ commit আর নির্বাচন দুটিতেই লাগে ⌊n ÷ ২⌋ + ১টি সম্মতি, আর leader নিজেও একটি। তাই ৫টি node সয় ২টি বিকলতা, ৬টিও ২টি — majority ৪ হয়ে যায়, সহনশীলতা বাড়ে না, উল্টো প্রতিটি commit-এ বেশি ack. সাধারণ সূত্র: f টি বিকলতা সইতে 2f + 1টি node. Latency-র দিকেও ফাঁদ: commit-এর সময় গড় RTT নয়, leader বাদে k-তম দ্রুততম follower-এর RTT — ৭টির cluster-এ তৃতীয় দ্রুততম।

Lease-এর মেয়াদ দেখা। একটি client lock পেল ১৫ সেকেন্ডের lease-এ। লেখার ঠিক আগে নিজের ঘড়িতে দেখল “এখনো ৩ সেকেন্ড বাকি”, তারপর GC pause-এ ২০ সেকেন্ড থেমে রইল। এর মধ্যে মেয়াদ ফুরিয়েছে, lock service অন্য client-কে lock দিয়েছে। প্রথমজন জেগে উঠে পুরোনো বিশ্বাসে লিখল — দুজন মালিক, ডেটা নষ্ট। মেয়াদ দেখা আর লেখার মাঝে যেকোনো থামা এই ফাঁক খোলে, আর কোনো client-ই নিজের থামা টের পায় না।

প্রতিকার fencing token: প্রতিবার lock দেওয়ার সময় বাড়তে থাকা একটি সংখ্যা (৩৩, তারপর ৩৪)। Storage প্রতিটি লেখায় token দেখে, আর আগে দেখা সবচেয়ে বড়টির চেয়ে ছোট token-এর লেখা ফেরায়। নিরাপত্তা তাই client-এর ঘড়িতে নয়, storage-এর যাচাইয়ে। Martin Kleppmann ২০১৬ সালের একটি প্রকাশ্য লেখায় এই উদাহরণটি জনপ্রিয় করেন।

মূল উপলব্ধি: Majority = ⌊n ÷ ২⌋ + ১, leader-সহ, আর জোড় n-এ লাভ নেই; lease একা নিরাপত্তা দেয় না — storage-কে fencing token যাচাই করতে হয় (পর্ব ৪২, ৪৩)।

শেষ ধাপ — ক্রম সাজান আর স্কোর দেখুন

উপরের সব MCQ শেষ করলে নিচে আপনার মোট স্কোর দেখাবে — প্রথম চেষ্টায় কয়টি ঠিক হয়েছে।

ক্রমএকজন ব্যবহারকারী প্রথমবার একটি পণ্যের পাতা খুললেন (কিছুই cache-এ নেই)। অনুরোধের ধাপগুলো আগে থেকে পরে সাজান (▲▼ চেপে সরান)

DNS resolver নাম থেকে কাছের CDN edge-এর IP দেয়
Edge-এর সাথে TCP আর TLS সংযোগ হয়
Edge-এ miss, তাই অনুরোধ যায় origin-এর load balancer-এ
Load balancer একটি সুস্থ stateless app server বাছে
App cache-এ খোঁজে, miss পায়
App database থেকে পড়ে মানটি cache-এ বসায়, তারপর উত্তর দেয়

শব্দকোষ

লেখার মধ্যে ডটেড দাগ দেওয়া শব্দে মাউস রাখুন বা চাপুন — অর্থ দেখাবে। এই পর্বের সব শব্দ এখানে একসাথে:

মনে রাখুন

শর্ত খুঁজুন, তারপর বাদ দিন: “কোন নকশা মানায়” প্রশ্নে আগে কঠিন requirement আর ব্যর্থতাটি ধরুন; প্রতিটি অপশনের পেছনের নিয়মটি খুঁজে কেটে দিন।
রীতি আর একক আগে লিখুন: দিন 86,400 s না 10⁵, bit না byte, nearest-rank percentile, series না parallel — একই প্রশ্নের দুটি “সঠিক” উত্তর দুই রীতি থেকেই আসে।
তিন বড় ভুল ব্যাখ্যা: CAP-এ “CA” নেই আর তার C ≠ ACID-এর C; R + W > N ≠ linearizable; exactly-once = at-least-once + idempotent consumer.
নিরাপদ মনে হওয়া ফাঁদ: cache-aside-এ দেরিতে আসা set, lease-এর মেয়াদ দেখে লেখা, স্তরে স্তরে retry আর read replica দিয়ে লেখা বাড়ানোর আশা।
ভুল থেকে নিয়ম: প্রতিটি ভুলের নিয়মটি খাতায় লিখুন, সংখ্যা বদলে আবার করুন, আর checker বা নিজের ছোট script-এ মিলিয়ে নিন — AI-এর বানানো প্রশ্নেও একই নিয়ম।

পরের পর্বে: MCQ চেনায় কোনটি সঠিক; লিখিত পরীক্ষা আর ভাইভা চায় কেন সঠিক। পর্ব ৬৪-এ scaling, storage, distributed systems আর architecture-এর লিখিত ও মৌখিক প্রশ্ন — কীভাবে ধাপে ধাপে উত্তর সাজাবেন, ছবি আঁকবেন আর trade-off বলবেন।

MCQ প্রশ্নব্যাংক — system design