Estimation আর trade-off-এর অনুশীলন — পূর্ণ সমাধানসহ হিসাব

(a) QPS = 5 x 10^7 / 86,400 = 578.7 req/s
(b) mental: 5 x 10^7 / 10^5 = 500 req/s
    500 / 578.7 = 0.864  -> 13.6% low;  fix: 500 x 1.16 = 580

মাথার হিসাবের কৌশল: “দিনে ১ লাখ ≈ সেকেন্ডে ১”, তাই ৫ কোটি = ৫০০ লাখ ≈ সেকেন্ডে ৫০০। মাত্রা ঠিক, শুধু ১৪%-এর মতো কম। যাচাই: একক — (অনুরোধ/দিন) ÷ (সেকেন্ড/দিন) = অনুরোধ/সেকেন্ড. উত্তর: ≈ ৫৭৯ req/s; মাথায় ৫০০, প্রায় ১৩.৬% কম। ঝালাতে: পর্ব ০৩।

(a) 10^9 bit/s / 8 = 1.25 x 10^8 B/s = 125 MB/s
(b) 1 TB = 8 x 10^12 bit;  8 x 10^12 / 10^8 = 80,000 s = 22.2 h
(c) 500 GB = 4 x 10^12 bit; 4 x 10^12 / 10^9 = 4,000 s = 66.7 min

সবচেয়ে বড় ফাঁদ ৮ গুণের: “১০০ Mbit/s মানে ১০০ MB/s” ধরলে (খ)-এর উত্তর ২.৮ ঘণ্টা আসত — আসলের আট ভাগের এক ভাগ। যাচাই: ১২৫ MB/s-এ ৫০০ GB = ৫০০,০০০ ÷ ১২৫ = ৪,০০০ সেকেন্ড — একই। এই ধরনের সংখ্যা DR-এ restore-সময়ের হিসাবে সরাসরি লাগে (ভাগ ৭)। উত্তর: ১২৫ MB/s; প্রায় ২২.২ ঘণ্টা; প্রায় ৬৬.৭ মিনিট। ঝালাতে: পর্ব ০৩।

(a) 6 x 150 ms = 900 ms;   100 x 0.5 ms = 50 ms;   total = 950 ms
(b) RAM : 1,000 x 100 ns = 0.1 ms
    SSD : 1,000 x 100 us = 0.1 s
    HDD : 1,000 x 10 ms  = 10 s
(c) RTT >= 2 x 3,000 km / 200,000 km/s = 0.03 s = 30 ms

(ক)-এর শিক্ষা: পরপর করা call-এর সংখ্যাই latency ঠিক করে। ছয়টি মহাদেশ-পেরোনো call-কে একসাথে (parallel) পাঠালে বা কাছের region-এ সরালে প্রায় ৭৫০ ms বাঁচে। (খ)-তে RAM থেকে hard disk পর্যন্ত লাফ এক লাখ গুণ — এজন্যই cache. (গ)-এর ৩০ ms কোনো প্রকৌশলে কমে না; বাস্তবে পথ বাঁকা আর router-এর অপেক্ষা যোগ হয় বলে মাপা মান বেশি। যাচাই: hard disk-এ সেকেন্ডে ১ ÷ ১০ ms = ১০০টি random read — পরিচিত IOPS-এর মাত্রা। উত্তর: ≈ ৯৫০ ms; ০.১ ms, ০.১ s আর ১০ s; অন্তত ৩০ ms. ঝালাতে: পর্ব ০৩ আর ০৭।

exact : 2.3 x 10^6 x 37 x 1,800 = 1.532 x 10^11 B  (153 GB)
(a)   : 2 x 10^6 x 4 x 10^1 x 2 x 10^3 = 16 x 10^10 = 1.6 x 10^11 B
        1.6 / 1.532 = 1.045  -> only 4.5% high (errors cancel)
(b)   : 3 x 10^6 x 4 x 10^1 x 2 x 10^3 = 2.4 x 10^11 B
        2.4 / 1.532 = 1.567  -> 57% high (errors add up)

(ক)-তে ২৩ লাখ নিচে (প্রায় ১৩%), ৩৭ আর ১,৮০০ ওপরে (৮% আর ১১%) গোল হয়েছে, তাই ভুলগুলো অনেকটা কাটাকাটি। (খ)-তে সব একদিকে বলে জমে গেছে — তবু এক মাত্রার (১০ গুণ) অনেক ভেতরে, তাই নকশার সিদ্ধান্ত বদলায় না। যাচাই: ঘাত যোগ — ৬ + ১ + ৩ = ১০, আর a-গুলোর গুণফল ১৬, তাই ১.৬ × ১০^১১. উত্তর: মাথায় ≈ ১৬০ GB বনাম ঠিক ≈ ১৫৩ GB (৪.৫% বেশি); সব ওপরে গোল করলে ≈ ২৪০ GB, প্রায় ১.৫৭ গুণ। ঝালাতে: পর্ব ০৩ (order of magnitude).

reads/day  = 2 x 10^7 x 10 = 2 x 10^8   -> 2 x 10^8 / 86,400 = 2,314.8 /s
writes/day = 2 x 10^7 x 1  = 2 x 10^7   -> 2 x 10^7 / 86,400 =   231.5 /s
peak x 4   : read 9,259 /s,  write 926 /s,  total 10,185 /s
read:write = 10 : 1

Read আর write আলাদা রাখার কারণ: দুটির নকশা আলাদা — read বাড়লে cache আর replica, write বাড়লে sharding আর queue. যাচাই: মাথায় ২ × ১০^৮ ÷ ১০^৫ = ২,০০০ — ২,৩১৫-এর মাত্রার সাথে মেলে। উত্তর: গড়ে read ≈ ২,৩১৫/s, write ≈ ২৩১.৫/s; peak-এ ≈ ৯,২৫৯ আর ≈ ৯২৬/s; অনুপাত ১০:১। ঝালাতে: পর্ব ০৩।

(a) 2 x 10^7 posts/day x 1 KB = 20 GB/day
    x 365 x 5 = 36.5 TB raw;  x 3 = 109.5 TB;  x 1.25 = 136.9 TB
(b) 0.1 x 2 x 10^7 = 2 x 10^6 photos/day x 500 KB = 1 TB/day
    x 365 = 365 TB raw;  x 3 = 1,095 TB = 1.095 PB per year
(c) 365 TB x 1.5 = 547.5 TB  (saves 547.5 TB a year)

মাত্র ১০% পোস্টে ছবি, তবু ছবির এক বছর লেখার পাঁচ বছরের প্রায় আট গুণ। Storage-এর নকশা তাই বড় ফাইলের দিকে তাকিয়ে হয়: ছবি database-এ নয়, object storage-এ; database-এ শুধু তার key (পর্ব ২৬)। যাচাই: প্রতি ছবি-পোস্টে ৫০০ গুণ বড় byte, আর ছবি-পোস্ট ১০ ভাগের ১ ভাগ, তাই প্রতিদিন ছবি লেখার ৫০ গুণ (১ TB বনাম ২০ GB) — মেলে। উত্তর: ≈ ১৩৬.৯ TB; ≈ ১.০৯৫ PB; ≈ ৫৪৭.৫ TB. ঝালাতে: পর্ব ০৩ আর ২৬।

(a) 10^6 x 3 x 10^6 bit/s = 3 x 10^12 bit/s = 3 Tbit/s
(b) origin = 3 Tbit/s x (1 - 0.95) = 150 Gbit/s
(c) 99%: 3 Tbit/s x 0.01 = 30 Gbit/s  -> 150 / 30 = 5x less

৩ Tbit/s কোনো একক data center-এর লিংকে আঁটে না — এই সংখ্যাই বলে দেয়, বিতরণ করতে হবে ব্যবহারকারীর কাছের CDN-এর edge থেকে (পর্ব ১৭)। লক্ষ করুন, offload ৯৫ থেকে ৯৯ — মাত্র ৪ শতাংশ বিন্দু — অথচ origin-এর চাপ ৫ গুণ কমে, কারণ চাপ ঠিক করে miss-এর অংশ (৫% বনাম ১%). যাচাই: ১০ লাখ × ৩ Mbit = ৩০ লাখ Mbit = ৩ × ১০^৬ Mbit = ৩ Tbit. উত্তর: ৩ Tbit/s; ১৫০ Gbit/s; ৫ গুণ (৩০ Gbit/s). ঝালাতে: পর্ব ১৭ আর ৫৯।

messages/day   = 5 x 10^7 x 40 = 2 x 10^9      -> 23,148 /s avg
deliveries/msg = 0.8 x 1 + 0.2 x 19 = 0.8 + 3.8 = 4.6
deliveries/day = 2 x 10^9 x 4.6 = 9.2 x 10^9   -> 106,481 /s avg
peak x 5       : 115,741 msg/s,  532,407 deliveries/s
egress at peak = 532,407 x 200 B x 8 = 851.9 Mbit/s

বার্তা লেখা হয় একবার, কিন্তু পৌঁছাতে হয় গড়ে ৪.৬ বার — এই fan-out-ই chat-এর আসল চাপ (পর্ব ৫৫)। “গড় group-এ ২০ জন” বললে ২০-কে নয়, ১৯-কে গুনতে হয় — প্রেরক নিজেকে পাঠান না (তবে তাঁর অন্য device-এ sync লাগতে পারে, সেটি আলাদা ধরে নেওয়া)। যাচাই: প্রতি ব্যবহারকারীর দিক থেকে — দিনে ৪০টি পাঠান, ৪০ × ৪.৬ = ১৮৪টি গ্রহণ — group-ভারী ব্যবহারে বিশ্বাসযোগ্য। উত্তর: গড়ে ≈ ২৩,১৪৮ বার্তা আর ≈ ১,০৬,৪৮১ delivery/s; peak-এ ≈ ১,১৫,৭৪১ আর ≈ ৫,৩২,৪০৭/s; egress ≈ ৮৫২ Mbit/s. ঝালাতে: পর্ব ০৩, ৩২ আর ৫৫।

(a) years: 100 + 150 + 225 + 337.5 = 812.5 TB
    formula: 100 x (1.5^4 - 1) / 0.5 = 100 x 4.0625 / 0.5 = 812.5 TB
(b) per day = 5 x 10^4 x 10^3 B x 86,400 = 4.32 TB raw;  x 3 = 12.96 TB
    days = 1,000 TB / 12.96 TB = 77.2 days

(ক)-তে বৃদ্ধি না ধরলে ৪০০ TB আসত — অর্ধেক। বৃদ্ধি একটি geometric series, আর চতুর্থ বছর একাই প্রায় মোটের ৪২%. (খ) হলো retention-এর উল্টো প্রশ্ন: জায়গা স্থির, দিন বের করতে হবে। সিদ্ধান্ত: ৭৭ দিনের বেশি রাখতে চাইলে পুরোনো log সস্তা storage-এ সরানো বা sampling. যাচাই: ৫০,০০০ × ১ KB = ৫০ MB/s; × ৮৬,৪০০ ≈ ৪.৩২ TB/দিন — মেলে। উত্তর: ৮১২.৫ TB; প্রায় ৭৭ দিন। ঝালাতে: পর্ব ০৩ আর ৫০।

(a) L = lambda x W = 2,000 /s x 0.150 s = 300 in flight;  300 / 8 = 37.5 per server
(b) L = 300 /s x 0.025 s = 7.5 connections busy   (pool 10: ok, 75%)
    slow DB: 300 /s x 0.100 s = 30 needed > 10 in the pool
    -> requests queue for a connection, W grows, threads pile up

Little-এর সূত্রের জোর হলো এটি বণ্টন জানতে চায় না — স্থিতিশীল যেকোনো সিস্টেমে দীর্ঘ সময়ের গড়ে খাটে (পর্ব ৪)। (খ)-এর দ্বিতীয় অংশই cascading failure-এর বীজ: database মরেনি, শুধু ধীর — তবু pool ফুরিয়ে app-এর সব thread আটকে যায় (পর্ব ৪৮)। তাই timeout-এর ঊর্ধ্বসীমা = pool ÷ হার = ১০ ÷ ৩০০ s ≈ ৩৩ ms-এর মতো যুক্তিতে বসে। যাচাই: একক — (অনুরোধ/s) × s = অনুরোধ। উত্তর: ৩০০টি (সার্ভারপ্রতি ৩৭.৫); ৭.৫টি connection; ধীর database-এ ৩০টি লাগবে — pool ফুরাবে। ঝালাতে: পর্ব ০৪ আর ৪৮।

rank = ceil(p x n),  n = 20
p50: ceil(10)   = 10th -> 22 ms
p90: ceil(18)   = 18th -> 60 ms
p95: ceil(19)   = 19th -> 110 ms
p99: ceil(19.8) = 20th -> 240 ms   (= the maximum)
mean = 804 / 20 = 40.2 ms

গড় ৪০.২ ms — যা আসলে কোনো অনুরোধের অভিজ্ঞতা নয়: ১৬টি অনুরোধ এর চেয়ে দ্রুত, আর ২টি অনেক ধীর। দুটি ধীর নমুনা গড়কে প্রায় ২৫ থেকে ৪০ ms-এ (প্রায় ১.৬ গুণ) তুলেছে, কিন্তু p50-কে ছোঁয়নি। ২০টি নমুনায় p99 আর সর্বোচ্চ একই — এত ছোট নমুনায় p99 বলার অর্থ নেই; অনেক টুল interpolation ব্যবহার করে বলে উত্তর আলাদা হয়, তাই পদ্ধতি লিখুন (পর্ব ৪)। যাচাই: যোগফল ৮০৪ — দশটি করে দুই ভাগে ১৭২ আর ৬৩২. উত্তর: ২২, ৬০, ১১০ আর ২৪০ ms; গড় ৪০.২ ms. ঝালাতে: পর্ব ০৪ আর ৫০ (percentile).

(a) P = 1 - 0.99^N
    N = 10 : 1 - 0.904 = 9.6%
    N = 50 : 1 - 0.605 = 39.5%
    N = 100: 1 - 0.366 = 63.4%
(b) (1 - p)^50 = 0.99  ->  1 - p = 0.99^(1/50) = 0.999799
    each shard slow only 0.0201% of the time  (about its p99.98)

প্রতিটি shard-এর p99 যত ভালোই হোক, fan-out বড় হলে পুরো অনুরোধের tail latency সেই shard-গুলোর p99.৯৮-এর মতো দুর্লভ ধীরতায় গিয়ে ঠেকে। প্রতিকার: কম fan-out, hedged request, timeout-এ আংশিক ফল আর cache (পর্ব ৪)। Dean ও Barroso-র “The Tail at Scale” (২০১৩) এই হিসাবকে বিখ্যাত করে। যাচাই: ছোট Np-এ আসন্ন মান — N = ১০-এ ১০%, সঠিক ৯.৬%, কাছাকাছি; N = ১০০-এ Np = ১০০% অসম্ভব, তাই সূত্রই লাগে। উত্তর: ≈ ৯.৬%, ৩৯.৫% আর ৬৩.৪%; প্রতিটি shard-কে ≈ ৯৯.৯৮% সময় দ্রুত হতে হবে। ঝালাতে: পর্ব ০৪।

(a) rho = lambda x S;  W = S / (1 - rho);  L = rho / (1 - rho);  p99 ~ 4.6 W
    lambda 25: rho 0.5, W = 20/0.5 = 40 ms,  L = 1, p99 ~ 184 ms
    lambda 40: rho 0.8, W = 20/0.2 = 100 ms, L = 4, p99 ~ 461 ms
    lambda 45: rho 0.9, W = 20/0.1 = 200 ms, L = 9, p99 ~ 921 ms
(b) S / (1 - rho) <= 50  ->  1 - rho >= 0.4  ->  rho <= 0.6
    lambda <= 0.6 / 0.020 s = 30 req/s

৪০ থেকে ৪৫ — চাপ মাত্র সাড়ে বারো শতাংশ বাড়ল, গড় সময় দ্বিগুণ। ১-এর কাছে বক্ররেখা খাড়া — এজন্যই peak-এ ৬০% লক্ষ্য (পর্ব ৩)। p99 ≈ ৪.৬W আসে M/M/1-এ মোট সময়ের exponential বণ্টন থেকে: P(T > t) = e^−t/W = ০.০১ হলে t = W ln ১০০. বাস্তব সিস্টেম এর চেয়ে বেশি এলোমেলো হলে tail আরও খারাপ। যাচাই: Little দিয়ে — λ = ৪০, W = ০.১ s, L = ৪ — সূত্রের L-এর সাথে মেলে। উত্তর: (০.৫, ৪০ ms, ১, ≈ ১৮৪ ms), (০.৮, ১০০ ms, ৪, ≈ ৪৬১ ms), (০.৯, ২০০ ms, ৯, ≈ ৯২১ ms); সর্বোচ্চ ৩০ req/s. ঝালাতে: পর্ব ০৪ (utilization).

(a) effective = 2,500 x 0.6 = 1,500 /s per server
    50,000 / 1,500 = 33.3 -> 34;  N + 2 = 36
    one down: 50,000 / (35 x 2,500) = 57.1% busy  (under 60%)
(b) 2 zones must carry everything: 50,000 / 2 = 25,000 /s per zone
    25,000 / 1,500 = 16.7 -> 17 per zone;  3 x 17 = 51 servers

(খ)-তে বাড়তি খরচ ৫১ বনাম ৩৪ — প্রায় ৫০%; দুটি zone হলে প্রতিটিকে পুরো peak টানতে হতো, ৩৪ + ৩৪ = ৬৮। Zone বাড়লে বাড়তি কমে, কিন্তু জটিলতা বাড়ে (ভাগ ৮-এর ৮.৫)। যাচাই: ৩৬টি সার্ভারের পূর্ণ ক্ষমতা ৯০,০০০/s — peak-এর ১.৮ গুণ, ৬০% লক্ষ্যের সাথে সংগত। উত্তর: ৩৪টি + ২ = ৩৬টি; একটি নষ্টে ≈ ৫৭.১%; zone-প্রতি ১৭টি, মোট ৫১টি। ঝালাতে: পর্ব ০৩, ০৫ আর ১৩ (headroom).

(a) queue grows by (lambda - mu) = 100 per second
    wait of a new arrival at time t = 100 t / 500 s
    100 t / 500 > 1.5  ->  t > 1.5 x 500 / 100 = 7.5 s
(b) sequential: 30 + 50 + 40 = 120 ms
    parallel  : max(30, 50, 40) + 5 = 55 ms

(ক): ৭.৫ সেকেন্ড পরে সার্ভিস পুরো গতিতে কাজ করেও এমন অনুরোধ সারছে যার ক্লায়েন্ট আগেই চলে গেছে — throughput সর্বোচ্চ, কিন্তু goodput শূন্যের দিকে। প্রতিকার সীমিত queue আর load shedding: বাড়তি ১০০/s-কে দরজাতেই দ্রুত “না” বলা (পর্ব ১৮)। (খ): পরপর call-এ সময় যোগ হয়, একসাথে call-এ সবচেয়ে ধীরটি ঠিক করে — তবে তখন fan-out-এর tail (৩.৩) মাথায় রাখতে হয়। যাচাই: t = ১০ s-এ queue ১,০০০টি, অপেক্ষা ১,০০০ ÷ ৫০০ = ২ s > ১.৫ s — সত্যিই পেরিয়েছে। উত্তর: ৭.৫ সেকেন্ড পরে; ১২০ থেকে ৫৫ ms. ঝালাতে: পর্ব ০৪ আর ১৮।

year = 525,600 min,  30-day month = 43,200 min
99.9%   : 525.6 min = 8 h 45 min 36 s / yr ;  43.2 min / month
99.95%  : 262.8 min = 4 h 22 min 48 s / yr ;  21.6 min / month
99.99%  :  52.56 min / yr                  ;   4.32 min / month
99.999% :   5.256 min = 5 min 15 s / yr    ;  25.9 s / month

একই শতাংশ, ভিন্ন প্রতিশ্রুতি: “৯৯.৯% মাসিক” প্রতি মাসে ৪৩ মিনিটের সীমা টানে, “৯৯.৯% বার্ষিক”-এ একটি ৮ ঘণ্টার বিপর্যয়ও চলে যায় (পর্ব ৫)। পাঁচ nine-এ মাসে ২৬ সেকেন্ড — মানুষ জেগে ল্যাপটপ খোলার আগেই শেষ, তাই লাগে স্বয়ংক্রিয় failover. যাচাই: প্রতিটি সারি আগেরটির দশ ভাগের এক (৯৯.৯৫% মাঝামাঝি)। উত্তর: টেবিলের মতো — যেমন ৯৯.৯৯%-এ বছরে ≈ ৫২.৬ মিনিট, মাসে ≈ ৪.৩২ মিনিট। ঝালাতে: পর্ব ০৫।

(a) 0.9999 x 0.9995 x 0.99 x 0.999 = 0.988417  -> 98.84%, 101.5 h/yr
(b) LB pair      : 1 - 0.0005^2              = 0.99999975
    app 2 of 3   : 0.99^3 + 3 x 0.99^2 x 0.01 = 0.999702
    DB pair      : 1 - 0.001^2               = 0.999999
    total = 0.9999 x 0.99999975 x 0.999702 x 0.999999 = 0.999601
          -> 99.96%, about 3.50 h/yr

শিকল তার দুর্বলতম কড়ির চেয়েও দুর্বল: (ক)-এ ৯৮.৮৪%, অথচ সবচেয়ে খারাপ অংশটিও ৯৯%. (খ)-এ সবচেয়ে বড় unavailability এখন app স্তরের ০.০০০২৯৮ — “৩-এর মধ্যে ২” মানে মাত্র একটি ব্যর্থতা সহ্য হয়; চতুর্থ app server দিলে পরের দুর্বল জায়গা হবে DNS. এটিই availability বাড়ানোর পদ্ধতি: সবচেয়ে বড় U খুঁজে সেটিকে কমানো। যাচাই: ছোট U-এর যোগ — ০.০০০১ + ০.০০০০০০২৫ + ০.০০০২৯৮ + ০.০০০০০১ ≈ ০.০০০৩৯৯, অর্থাৎ ≈ ৯৯.৯৬%. উত্তর: ≈ ৯৮.৮৪% (বছরে ≈ ১০১.৫ ঘণ্টা); redundancy-তে ≈ ৯৯.৯৬% (≈ ৩.৫ ঘণ্টা)। ঝালাতে: পর্ব ০৫।

(a) 1 - 0.005^2 = 0.999975                     -> 13.1 min/yr
(b) zone in SERIES with the pair:
    0.9999 x 0.999975 = 0.999875                -> 65.7 min/yr
(c) each path = zone x server = 0.9999 x 0.995 = 0.9949005
    1 - (1 - 0.9949005)^2 = 0.999974            -> 13.7 min/yr

একই zone-এ দুটি কপি রাখলে কাগজের ১৩ মিনিট আসলে ৬৬ মিনিট — zone একাই series-এ বসে সব খেয়ে ফেলে। এটিই correlated failure হিসাবে আনার কৌশল: ভাগ করা অংশকে আলাদা করে series-এ বসানো (পর্ব ৫)। আলাদা availability zone-এ প্রায় কাগজের মানে ফেরা যায়। যাচাই: (খ)-এর U ≈ ০.০০০১ (zone) + ০.০০০০২৫ (জোড়া) = ০.০০০১২৫ — মেলে। উত্তর: ≈ ৯৯.৯৯৭৫% (১৩.১ মিনিট), ≈ ৯৯.৯৮৭৫% (৬৫.৭ মিনিট), ≈ ৯৯.৯৯৭৪% (১৩.৭ মিনিট)। ঝালাতে: পর্ব ০৫ আর ৫১।

(a) A = 720 / (720 + 2)    = 0.997230 -> 24.27 h/yr
(b) A = 720 / (720 + 1)    = 0.998613 -> 12.15 h/yr
(c) MTTR = 2 + 30 + 10 + 10 = 52 min = 0.867 h
    A = 720 / 720.867      = 0.998798 -> 10.53 h/yr

(গ)-তে MTBF একটুও বাড়েনি — একই হারে ব্যর্থতা — অথচ downtime ২৪ থেকে সাড়ে ১০ ঘণ্টা। U ≈ MTTR ÷ MTBF বলে MTTR অর্ধেক করা আর MTBF দ্বিগুণ করা একই ফল দেয়, আর দ্রুত টের পাওয়া ও rollback প্রায়ই অনেক সস্তা (পর্ব ৫ আর ৫৩)। যাচাই: (ক) U ≈ ২ ÷ ৭২২ ≈ ০.০০২৭৭; × ৮,৭৬০ ≈ ২৪.৩ ঘণ্টা — মেলে। উত্তর: ≈ ৯৯.৭২% (২৪.৩ ঘণ্টা); ≈ ৯৯.৮৬% (১২.১৫); ≈ ৯৯.৮৮% (১০.৫ ঘণ্টা)। ঝালাতে: পর্ব ০৫।

(a) budget = (1 - 0.999) x 43,200 min = 43.2 min
    or 0.001 x 5 x 10^8 = 500,000 failed requests
(b) full outage          : 25 min x 100% = 25.0 min-equivalent
    partial (2 h at 3%)  : 120 min x 0.03 = 3.6 min-equivalent
    used = 28.6 / 43.2 = 66.2%;   left = 14.6 min

অনুরোধ-ভিত্তিক SLO-তে বাজেট আসলে ব্যর্থ অনুরোধের সংখ্যা; “মিনিট” হলো পূর্ণ বিভ্রাটের সমতুল্য। আংশিক ত্রুটি তাই তার অনুপাতে খরচ হয় — ২ ঘণ্টার ৩% ত্রুটি মাত্র ৩.৬ মিনিটের সমান। দুই-তৃতীয়াংশ বাজেট শেষ বলে error budget policy অনুযায়ী ঝুঁকিপূর্ণ release ধীর করা যুক্তিসংগত (পর্ব ৫০)। যাচাই: অনুরোধ গুনে — ২ ঘণ্টায় ৫০ কোটি × ১২০ ÷ ৪৩,২০০ ≈ ১৩,৮৮,৮৮৯টি অনুরোধ, তার ৩% ≈ ৪১,৬৬৭টি ব্যর্থ, যা ৫,০০,০০০-এর ৮.৩৩%; আর ৩.৬ ÷ ৪৩.২-ও ৮.৩৩% — দুই পথে মেলে। উত্তর: ৪৩.২ মিনিট বা ৫,০০,০০০টি অনুরোধ; ব্যবহার ≈ ৬৬.২%, বাকি ≈ ১৪.৬ মিনিট। ঝালাতে: পর্ব ০৫ আর ৫০ (SLI).

window = 30 x 24 = 720 h;  budget fraction = 0.001
(a) burn = 0.005 / 0.001 = 5;  empty in 720 / 5 = 144 h = 6 days
    per hour: 5 / 720 = 0.694% of the budget
(b) 2% in 1 h: burn = 0.02 x 720 / 1 = 14.4 -> error ratio 14.4 x 0.1% = 1.44%
(c) burn 2: 720 / 2 = 360 h = 15 days

Burn rate ১ মানে ঠিক জানালার শেষে বাজেট শূন্য; ১৪.৪ মানে ৫০ ঘণ্টায় শূন্য। ১.৪৪% error শুনতে ছোট, কিন্তু এই গতিতে দুই দিনে পুরো মাসের বাজেট শেষ — তাই page. প্রচলিত multiwindow alert দুই জানালায় একসাথে দেখে, যেমন ১ ঘণ্টা আর ৫ মিনিট দুটিতেই ১৪.৪-এর বেশি, যাতে সমস্যা থামলে alert দ্রুত থামে (পর্ব ৫০)। যাচাই: (ক) ৬ দিন × ২৪ = ১৪৪ ঘণ্টা; ১৪৪ × ০.৬৯৪% ≈ ১০০% — মেলে। উত্তর: burn ৫, ১৪৪ ঘণ্টায় (৬ দিন), ঘণ্টায় ≈ ০.৬৯%; burn ১৪.৪ মানে error ≈ ১.৪৪%; ১৫ দিনে। ঝালাতে: পর্ব ৫০।

(a) storage: 40 TB / (2 TB x 0.7) = 28.6 -> 29 shards
    writes : 60,000 / 5,000       = 12 shards
    take the larger: 29 shards;  x 3 replicas = 87 nodes
(b) 500^3 = 1.25 x 10^8;  500^4 = 6.25 x 10^10 >= 10^10  -> 4 levels
    (log_500 10^10 = 3.71, round up)

দুটি আলাদা কারণে shard লাগে — জায়গা আর লেখার হার — আর যেটি বড়, সেটিই উত্তর। এখানে storage-ই ঠিক করছে; লেখার জন্য ১২টিই যথেষ্ট ছিল। (খ)-তে মাত্র ৪টি স্তর মানে প্রতিটি খোঁজায় সর্বোচ্চ ৪টি page — ওপরের স্তরগুলো সাধারণত memory-তে থাকে (পর্ব ১৯)। যাচাই: ২৯ × ১.৪ TB = ৪০.৬ TB ≥ ৪০ TB. উত্তর: ২৯টি shard, ৮৭টি node; ৪টি স্তর। ঝালাতে: পর্ব ১৯ আর ২৩ (sharding).

(a) mod N: moved fraction = N/(N+1) = 10/11 = 90.9% -> 9.09 x 10^8 keys
(b) ring : expected 1/(N+1) = 1/11 = 9.09%           -> 9.09 x 10^7 keys
(c) 1,024 / 10 = 102.4 -> 4 nodes keep 103, 6 nodes hold 102
    give each new node 102 (old nodes keep 4 x 103 + 4 x 102 = 820)
    moved = 2 x 102 = 204 partitions = 19.9%

mod N-এ cluster বড় হওয়াটাই শাস্তি — ৯১% key নতুন জায়গায়, cache-এ ঢল আর database-এ বিপুল কপি। Ring আর নির্দিষ্ট partition দুটিতেই সরে শুধু যতটা নতুন node-এর ন্যায্য ভাগ, আর তার কম সম্ভব নয় (পর্ব ১৬ আর ২৩)। যাচাই: (গ)-তে দুটি নতুন node পুরো ১০ ভাগের ২ ভাগ পায়, ২০% — ২০৪ ÷ ১,০২৪ = ১৯.৯%, মেলে। উত্তর: ≈ ৯০.৯ কোটি key (৯০.৯%); ≈ ৯.০৯ কোটি (৯.০৯%); ২০৪টি partition. ঝালাতে: পর্ব ১৬ আর ২৩।

sd/avg = sqrt((N - 1) / (N V + 1)),  N = 20
(a) V = 1  : sqrt(19 / 21)   = 95.1%
    V = 10 : sqrt(19 / 201)  = 30.7%
    V = 100: sqrt(19 / 2001) =  9.7%
(b) V = (N - 1) / (N c^2) = 19 / (20 x 0.0025) = 380   (~ 1/c^2 = 400)

V দশ গুণ করলে ছড়ানো কমে মাত্র √১০ ≈ ৩.১৬ গুণে — ভাগ দশ গুণ সমান করতে বিন্দু লাগে একশো গুণ। (গ): V বাড়ায় key-সংখ্যার ভাগ সমান করে, কিন্তু একটি key একটিই জায়গায় থাকে; তার সব অনুরোধ একই সার্ভারে যায়, যত V-ই থাকুক। Hot key-এর ওষুধ আলাদা (৫.৪)। যাচাই: V = ৩৮০ বসালে √(১৯ ÷ ৭,৬০১) ≈ ০.০৫০০ — ঠিক ৫%. উত্তর: ≈ ৯৫%, ৩১% আর ৯.৭%; V ≈ ৩৮০ (মোটামুটি ৪০০)। ঝালাতে: পর্ব ১৬।

average per shard = 400,000 / 40 = 10,000 /s
hot key = 0.02 x 400,000 = 8,000 /s;  the rest = 392,000 / 40 = 9,800 per shard
(a) hot shard = 9,800 + 8,000 = 17,800 /s  (1.78 x avg, over 15,000)
(b) 4 copies : 9,800 + 8,000 / 4 = 11,800 /s
(c) L1 90%   : 9,800 + 8,000 x 0.1 = 10,600 /s

গড়ের হিসাবে cluster-এ প্রচুর জায়গা (৪০ × ১৫,০০০ = ৬ লাখ/s), তবু একটি shard ডুবছে — ক্ষমতা ঠিক করে সবচেয়ে ব্যস্ত shard, গড় নয়। প্রতিকার: hot key চেনা (sampling বা top-k), কয়েকটি কপি, অল্প TTL-এর local cache আর একই key-এর অনুরোধ এক করা (পর্ব ৩০)। Local cache-এর দাম staleness: TTL ২ সেকেন্ড হলে like-সংখ্যা ২ সেকেন্ড পুরোনো থাকতে পারে। যাচাই: (ক)-এ মোট = ৩৯ × ৯,৮০০ + ১৭,৮০০ = ৪,০০,০০০ — মেলে। উত্তর: ১৭,৮০০/s (সীমা ছাড়ায়); ১১,৮০০/s; ১০,৬০০/s. ঝালাতে: পর্ব ২৩ আর ৩০।

(a) DB = 100,000 x (1 - h);  avg = 1 + (1 - h) x 20 ms
    h 90%: 10,000 /s, 3.0 ms   h 95%: 5,000 /s, 2.0 ms   h 99%: 1,000 /s, 1.2 ms
(b) before: 100,000 x 0.02 = 2,000 /s
    after : 2,000 x 7/8 + 100,000 / 8 = 1,750 + 12,500 = 14,250 /s
    x 7.125  (= 1 + h / (N (1 - h)) = 1 + 0.98 / 0.16)
(c) cold: 100,000 /s = 50 x the normal 2,000

Hit ratio ৯৫ থেকে ৯৯ — চার শতাংশ বিন্দু — অথচ database-এর চাপ পাঁচ ভাগের এক ভাগ, কারণ চাপ ঠিক করে miss. উল্টো দিকে, cache যত ভালো, তার একটি shard হারানো তত বিপজ্জনক: h বেশি হলে database ছোট করে কেনা হয়, অথচ একটি shard পড়লেই চাপ সাত গুণ। তাই cache-কেও capacity plan-এ রাখতে হয় — replica, ধীরে traffic ফেরানো, coalescing (পর্ব ২৮ আর ৩০)। যাচাই: (খ)-তে বিকল shard-এর ভাগ ১২,৫০০/s পুরোটাই database-এ, বাকি ৭ ভাগে আগের মতো ২% miss — যোগ ১৪,২৫০. উত্তর: (১০,০০০/s, ৩ ms), (৫,০০০, ২ ms), (১,০০০, ১.২ ms); ≈ ৭.১২৫ গুণ; ৫০ গুণ। ঝালাতে: পর্ব ২৮, ২৯ আর ৩০ (hit ratio).

(a) backlog = (5,000 - 4,000) x 600 s = 600,000 changes
    after t s the follower has applied 4,000 t = what the leader wrote by 4,000 t / 5,000 = 0.8 t
    lag = t - 0.8 t = 0.2 x 600 = 120 s behind
(b) catch-up = 600,000 / (4,000 - 2,000) = 300 s
(c) up to the last ~120 s of writes (600,000 changes) not yet on the follower

Lag সময়ের মাপে বলা ভালো — “follower ১২০ সেকেন্ড পেছনে” — কারণ সেটিই সরাসরি বলে, read replica থেকে কত পুরোনো ডেটা আসবে আর failover-এ কত সময়ের লেখা হারাতে পারে (RPO, পর্ব ৫১)। ধরে ফেলার সময় ঠিক করে বাড়তি ক্ষমতা (৪,০০০ − ২,০০০), পুরো ক্ষমতা নয় — ব্যাংকের কাউন্টারে ভিড় সরে শুধু ক্যাশিয়ারের অলস সময় দিয়ে। যাচাই: ৩০০ সেকেন্ডে follower ১২ লাখ প্রয়োগ করে, ওই সময়ে নতুন লেখা ৬ লাখ, backlog ৬ লাখ — শূন্যে নামে। উত্তর: ৬,০০,০০০টি, ১২০ সেকেন্ড পেছনে; ৩০০ সেকেন্ড; শেষ প্রায় ১২০ সেকেন্ডের লেখা। ঝালাতে: পর্ব ২২ আর ৫১।

overlap = W + R - N;  write survives N - W down;  read survives N - R down
(a) N=3 (2,2): overlap 1, write ok with 1 down, read ok with 1 down
        (3,1): overlap 1, write ok with 0 down, read ok with 2 down
        (1,3): overlap 1, write ok with 2 down, read ok with 0 down
(b) N=5 (3,3): overlap 1, both ok with 2 down
(c) (1,1): 1 + 1 = 2, not > 3 -> a read may miss the latest write entirely

(২, ২) জনপ্রিয় কারণ দুই দিকেই একটি করে ব্যর্থতা সহ্য হয়; (৩, ১) পড়াকে সস্তা করে কিন্তু একটি replica বন্ধ হলেই লেখা থামে। মনে রাখুন, overlap থাকলেই linearizable নয় — চলমান লেখা, আংশিক ব্যর্থ লেখা, sloppy quorum আর LWW-এ পুরোনো মান আসতে পারে (পর্ব ৪১)। যাচাই: প্রমাণের লাইন — দুটি দলের মিলন ≤ N, তাই ছেদ ≥ W + R − N ≥ ১. উত্তর: টেবিলের মতো; N = ৫, (৩, ৩)-এ দুই দিকেই ২টি; (১, ১)-এ overlap-এর নিশ্চয়তা নেই। ঝালাতে: পর্ব ৪১ (quorum intersection).

(a) n : majority  tolerated
    3 :    2         1
    4 :    3         1     (one more machine, no more safety)
    5 :    3         2
    7 :    4         3
(b) commit needs 3 of 5 (leader counts itself) = 2 more acks
    leader in A: A-peer ~1 ms, then nearest remote = B at 30 ms -> ~30 ms
    leader in C: acks from B at 70 ms, B at 70 ms              -> ~70 ms
    lose A (2) or B (2): 3 left = majority -> new leader, carries on
    lose C (1): 4 left -> carries on

জোড় সংখ্যার cluster-এ majority বাড়ে, কিন্তু সহ্যক্ষমতা বাড়ে না — দাম বাড়ে, নিরাপত্তা নয়। তাই ৩ বা ৫। (খ)-তে দেখুন, প্রতিটি commit majority-র সাথে একটি round trip, তাই leader কোথায় বসে তা লেখার latency ঠিক করে; leader A বা B-তে রাখা ভালো (পর্ব ৪২)। ২-২-১ বিন্যাস যেকোনো একটি region হারানো সহ্য করে — ৩-২ হলে বড় region-টি হারালে majority থাকত না। যাচাই: দুটি majority সবসময় অন্তত একজনে মেলে (৩ + ৩ > ৫), তাই এক term-এ দুজন leader হতে পারেন না, আর commit হওয়া entry পরের যেকোনো majority-তেও থাকে। উত্তর: (২, ১), (৩, ১), (৩, ২), (৪, ৩); leader A-তে ≈ ৩০ ms, C-তে ≈ ৭০ ms; যেকোনো একটি region হারালেও চলবে। ঝালাতে: পর্ব ৪২।

(a) n = 1,000 : log2 1000 + ln 1000 = 9.97 + 6.91 = 16.9 rounds ~ 17 s
    n = 10,000: 13.29 + 9.21 = 22.5 rounds ~ 23 s
(b) all-to-all: n (n - 1) = 1,000 x 999 = 999,000 messages per second
    SWIM      : ~ 2n = 2,000 (one ping + one ack per member per period)

Node দশ গুণ হলে রাউন্ড বাড়ে মাত্র ৫–৬টি — লগারিদমের জাদু। প্রথম log₂ n রাউন্ডে জানা লোক মোটামুটি দ্বিগুণ হয়, তারপর অজানা অংশ প্রতি রাউন্ডে প্রায় e গুণ কমে — সেটিই ln n অংশ (পর্ব ৪৪)। All-to-all heartbeat বার্তায় n² বাড়ে, তাই বড় cluster-এ অচল। যাচাই: ২^১০ = ১,০২৪ ≈ ১,০০০, তাই log₂ ১,০০০ ≈ ১০ — মেলে। উত্তর: ≈ ১৭ আর ≈ ২৩ সেকেন্ড; ৯,৯৯,০০০ বনাম ≈ ২,০০০ বার্তা। ঝালাতে: পর্ব ৪৪।

(a) bits/key = -ln p / (ln 2)^2;  k = bits/key x ln 2
    p = 1%  : 9.59 bit/key -> 9.59 x 10^8 bit = 119.8 MB, k = 6.64 -> 7
    p = 0.1%: 14.38 bit/key -> 179.7 MB, k = 9.97 -> 10
(b) p = (1 - e^(-7/10))^7 = (1 - 0.4966)^7 = 0.0082 -> 0.82%
(c) 10^8 x 200 B = 20 GB (before any hash-table overhead)

ভুল দশ গুণ কমাতে প্রতি key-এ মাত্র প্রায় ৪.৮ bit বেশি লাগে, আর key-এর আকার কোনো ভূমিকা রাখে না — ২০০ byte-এর URL আর ৮ byte-এর id দুটোরই ৯.৬ bit. দাম: “আছে” উত্তর মাঝে মাঝে মিথ্যা, তাই চূড়ান্ত সিদ্ধান্তের আগে আসল store-এ একবার মিলিয়ে নিতে হয় — false positive মানে সামান্য বাড়তি কাজ, false negative কখনো নয় (পর্ব ৪৫)। যাচাই: ১২০ MB বনাম ২০ GB — প্রায় ১৬৭ গুণ কম memory. উত্তর: ≈ ৯.৬ bit, ≈ ১২০ MB, ৭টি hash; ≈ ১৪.৪ bit, ≈ ১৮০ MB, ১০টি; ≈ ০.৮২%; ২০ GB. ঝালাতে: পর্ব ৪৫।

(a) w = ceil(e / 0.001) = 2,719;  d = ceil(ln 100) = ceil(4.61) = 5
    2,719 x 5 = 13,595 counters x 4 B = 54.4 KB
    overcount <= 0.001 x 10^9 = 10^6 with probability 0.99
(b) m = 2^14 = 16,384;  error = 1.04 / 128 = 0.81%;  16,384 x 6 bit = 12 KiB
    2%: m >= (1.04 / 0.02)^2 = 2,704 -> p = 12 (m = 4,096, error 1.625%)

Count-min কখনো কম দেখায় না, শুধু বেশি — তাই “সবচেয়ে বেশি চাওয়া জিনিস” খোঁজায় চলে, কিন্তু বিলের মতো নির্ভুল গণনায় নয়। লক্ষ করুন, ১০ লাখের বাড়তি ভুল মোট N-এর তুলনায়; একটি বিরল key-এর ১০০টি গণনার পাশে তা বিশাল, তাই CMS কাজে লাগে বড় গণনার key-এ (heavy hitters). HyperLogLog ১০০ কোটি আলাদা id-ও ১২ KiB-এ গোনে, যেখানে exact set-এ শুধু id-ই ৮ GB (পর্ব ৪৫)। যাচাই: √১৬,৩৮৪ = ১২৮, আর ১.০৪ ÷ ১২৮ = ০.০০৮১২৫. উত্তর: w = ২,৭১৯, d = ৫, ≈ ৫৪.৪ KB; ≈ ০.৮১%, ১২ KiB; p = ১২. ঝালাতে: পর্ব ৪৫।

(a) M = 62^7 = 3,521,614,606,208 (~3.52 x 10^12)
    expected pairs = n^2 / 2M = 10^14 / 7.04 x 10^12 = 14.2
    P(at least one) = 1 - e^(-14.2) ~ 1  (practically certain)
(b) n50 = sqrt(2 ln 2 x M) = 1.177 x sqrt(M) = 2.21 x 10^6 links
(c) M = 2^64 = 1.84 x 10^19;  10^18 / 3.69 x 10^19 = 0.027 -> P ~ 2.7%

৩.৫ লাখ কোটি জায়গা শুনতে অফুরন্ত, অথচ মাত্র ২২ লাখ link-এই সংঘর্ষের সম্ভাবনা অর্ধেক — কারণ প্রতিটি নতুন code আগের সবগুলোর সাথে মেলার সুযোগ পায়, জোড়ার সংখ্যা n²-এর মতো বাড়ে। তাই এলোমেলো code-এ প্রতিটি লেখা শর্তসাপেক্ষ (“না থাকলে তবেই লেখা”) আর মিললে আবার চেষ্টা; অথবা counter + base62, যেখানে সংঘর্ষই নেই কিন্তু code অনুমেয় (পর্ব ৫৪)। যাচাই: √M ≈ ১.৮৮ × ১০^৬; × ১.১৭৭ ≈ ২.২১ × ১০^৬ — পর্ব ৫৪-এর ২২,০৯,৫২৪-এর সাথে মেলে। উত্তর: ≈ ৩.৫২ × ১০^১২, প্রত্যাশিত ≈ ১৪টি, প্রায় নিশ্চিত; ≈ ২২ লাখ link; প্রায় ২.৭%. ঝালাতে: পর্ব ২৩ আর ৫৪।

(a) 2^41 ms = 2.199 x 10^12 ms = 2.199 x 10^9 s = 69.7 years
    epoch 2020 -> runs out around 2089
(b) per worker: 2^12 = 4,096 per ms = 4,096,000 per s
    workers: 2^10 = 1,024 -> cluster 4.19 x 10^9 per s
(c) refuse or wait 5 ms; never reuse an old timestamp (duplicates)

এক ms-এ ৪,০৯৬টির বেশি লাগলে worker পরের ms-এর অপেক্ষা করে। ঘড়ি পেছালে (NTP-এর সংশোধনে, পর্ব ৩৯) একই সময় আবার এলে একই ID বেরোনোর ঝুঁকি — তাই অপেক্ষা বা প্রত্যাখ্যান। ID সময়ক্রমে বাড়ে বলে index-এ ভালো, কিন্তু base62-এ ১১ অক্ষর — ছোট link-এর জন্য লম্বা (পর্ব ২৩ আর ৫৪)। যাচাই: ২^৪১ ≈ ২.২ × ১০^১২; ÷ (১,০০০ × ৮৬,৪০০ × ৩৬৫.২৫) ≈ ৬৯.৭. উত্তর: ≈ ৬৯.৭ বছর, ২০৮৯ সালের দিকে; ৪০,৯৬,০০০/s, cluster-এ ≈ ৪.১৯ × ১০^৯/s; অপেক্ষা বা প্রত্যাখ্যান। ঝালাতে: পর্ব ২৩ আর ৩৯।

(a) t=0 : tokens 50        ask 80  -> admit 50, left 0
    t=2 : 0 + 2 x 10 = 20  ask 30  -> admit 20, left 0
    t=3 : 0 + 10 = 10      ask 5   -> admit 5,  left 5
    t=10: min(50, 5 + 70)  ask 200 -> admit 50, left 0
    bound for any T seconds: b + r T = 50 + 10 x 10 = 150
(b) estimate = 80 x (1 - 0.25) + 30 = 60 + 30 = 90  -> 10 more

Bucket burst-কে অনুমতি দেয় (প্রথমেই ৫০টি), কিন্তু দীর্ঘ সময়ে গড় হার r-এ বাঁধে। t = ১০-এ ৭৫টি token জমার কথা ছিল, কিন্তু ক্ষমতা ৫০-এ আটকে গেল — অলস থেকে অসীম সঞ্চয় হয় না। (খ)-র অনুমান ধরে নেয় আগের মিনিটের ৮০টি সমানভাবে ছড়ানো ছিল; fixed window হলে মিনিটের সীমানায় দুই সেকেন্ডে ২০০টি ঢুকতে পারত (পর্ব ৪৯)। যাচাই: ০ থেকে ৩ সেকেন্ডে ঢুকেছে ৭৫টি ≤ ৫০ + ১০ × ৩ = ৮০ — সীমার ভেতরে। উত্তর: ৫০, ২০, ৫ আর ৫০টি; ১০ সেকেন্ডে সর্বোচ্চ ১৫০; আরও ১০টি। ঝালাতে: পর্ব ৪৯।

(a) 3 layers x 3 attempts each: 3^3 = 27 calls on the DB per user request
    1,000 req/s x 27 = 27,000 calls/s on a database that is already down
(b) waits = 100, 200, 400, 800, 1,600, 3,200 ms (cap 10 s not reached)
    total = 6,300 ms;  full jitter: uniform(0, w) -> average 3,150 ms

সুস্থ হয়ে ফেরার মুহূর্তে DB-কে ২৭ গুণ চাপ সামলাতে হয় — retry তখন সাহায্য নয়, আক্রমণ। প্রতিকার: শুধু একটি স্তরে retry (সাধারণত সবচেয়ে বাইরের বা সবচেয়ে ভেতরের, নকশা অনুযায়ী), retry budget (যেমন মোট অনুরোধের ১০%-এর বেশি retry নয়) আর circuit breaker (পর্ব ৪৮)। Jitter মোট অপেক্ষা কমানোর জন্য নয়, ক্লায়েন্টদের একসাথে ফেরা ভাঙার জন্য। যাচাই: জ্যামিতিক ধারা — ১০০ × (২^৬ − ১) = ৬,৩০০ ms. উত্তর: ২৭ বার, সেকেন্ডে ২৭,০০০; ৬.৩ সেকেন্ড, jitter-এ গড়ে ≈ ৩.১৫ সেকেন্ড। ঝালাতে: পর্ব ১৮ আর ৪৮।

(a) daily full only : worst loss = 24 h + 2 h to be safe = 26 h
    + WAL every 5 min: worst loss ~ 5 min (plus shipping delay)
(b) detect + decide            30.0 min
    new instance               15.0 min
    restore 2 TB @ 400 MB/s    2 x 10^12 / 4 x 10^8 = 5,000 s = 83.3 min
    replay 300 GB @ 100 MB/s   3 x 10^11 / 10^8     = 3,000 s = 50.0 min
    RTO ~ 178.3 min = 2.97 h   (target 2 h missed by ~1 h)

সবচেয়ে খারাপ RPO ২৪ নয়, ২৬ ঘণ্টা: নতুন backup নিরাপদে পৌঁছানোর আগেই বিপর্যয় হলে আগের রাতেরটি থেকে ফিরতে হয়। RTO-র সবচেয়ে বড় দুটি অংশ ডেটা সরানো — ২ ঘণ্টায় নামাতে হলে আরও ঘন ঘন base backup (replay ছোট হয়), দ্রুত restore-এর storage snapshot, বা আগে থেকে চালু একটি warm standby — যেখানে restore-ই লাগে না, শুধু promote (পর্ব ৫১)। এই সংখ্যাগুলো কাগজের; আসল RTO মাপা যায় শুধু restore-মহড়ায়। যাচাই: ৪০০ MB/s = ১.৪৪ TB/ঘণ্টা, তাই ২ TB-তে প্রায় ১.৩৯ ঘণ্টা ≈ ৮৩ মিনিট — মেলে। উত্তর: ২৬ ঘণ্টা; প্রায় ৫ মিনিট; RTO ≈ ১৭৮ মিনিট (≈ ৩ ঘণ্টা)। ঝালাতে: পর্ব ৫১ (point-in-time recovery).

monthly requests = 10,000 x 30 x 86,400 = 2.592 x 10^10;  budget = 0.1% = 2.592 x 10^7
(a) canary: 10,000 x 0.01 x 1,800 s x 0.2 = 36,000 failed -> 0.14% of budget
(b) full  : 10,000 x 1,800 s x 0.2       = 3,600,000 failed -> 13.9% of budget

Canary ক্ষতিকে ১০০ ভাগের এক ভাগে নামায় — আর ৩০ মিনিট নয়, ভালো automated analysis-এ কয়েক মিনিটেই ধরা পড়ার কথা। তবে ছোট ভাগে নমুনা ছোট: ১% traffic-এ বিরল ত্রুটি (যেমন ০.১% বাড়তি) প্রমাণ হতে অনেক বেশি সময় লাগে, তাই canary ধাপে ধাপে বাড়ে (১% → ১০% → ৫০%) (পর্ব ৫৩)। যাচাই: অনুপাত ৩৬,০০,০০০ ÷ ৩৬,০০০ = ১০০ — ঠিক canary-র ভাগের উল্টো। উত্তর: ৩৬,০০০টি, বাজেটের ≈ ০.১৪%; ৩৬ লাখ, ≈ ১৩.৯%. ঝালাতে: পর্ব ৫০ আর ৫৩।

(a) surge 25%: ceil(40 x 0.25) = 10 per wave -> 40 / 10 = 4 waves  x 3 = 12 min (max 50 pods)
    surge 10%: ceil(40 x 0.10) = 4 per wave  -> 40 / 4  = 10 waves x 3 = 30 min (max 44 pods)
(b) surge = ceil(2.5) = 3 -> at most 13 pods
    unavailable = floor(2.5) = 2 -> at least 8 ready

Surge হলো গতি আর বাড়তি ক্ষমতার trade-off: ২৫%-এ ১২ মিনিট কিন্তু মুহূর্তে ১০টি বাড়তি pod-এর জায়গা লাগে; ১০%-এ মাত্র ৪টি বাড়তি, কিন্তু ৩০ মিনিট — আর সেই পুরো সময় দুই সংস্করণ একসাথে চলে, তাই API আর database দুই সংস্করণের সাথেই মানানসই থাকতে হয় (expand/contract, পর্ব ৫৩)। গোল করার দিক ইচ্ছাকৃত: surge ওপরে, unavailable নিচে — দুটিই নিরাপদ দিকে। যাচাই: (খ) ১০ + ৩ = ১৩, ১০ − ২ = ৮ — পর্ব ৫৩-এর উদাহরণের সাথে মেলে। উত্তর: ১২ আর ৩০ মিনিট; সর্বোচ্চ ১৩টি pod, কমপক্ষে ৮টি প্রস্তুত। ঝালাতে: পর্ব ৫৩ (rolling deployment).

push: 10^7 posts x 500 = 5 x 10^9 inserts/day = 57,870 /s
pull: 4 x 10^8 reads x 200 followees = 8 x 10^10 fetches/day = 925,926 /s
celebrity: 5 x 10^7 inserts / 10^5 per s = 500 s = 8.3 min for ONE post

সংখ্যা: push-এ কাজ প্রায় ১৬ গুণ কম, আর feed খোলা মানে শুধু একটি তৈরি তালিকা পড়া — read-ভারী সেবায় push জেতে। কোথায় ভাঙে: লম্বা লেজ — একজন তারকার একটি পোস্টেই ৮ মিনিট insert, আর সেই সময়ে বাকিদের কাজ পিছিয়ে যায়। সিদ্ধান্ত: hybrid — সাধারণ ব্যবহারকারীর জন্য push, সীমার (যেমন কয়েক লাখ follower) ওপরের অ্যাকাউন্টের পোস্ট পড়ার সময় pull করে মিশিয়ে দেওয়া; অনুপস্থিত ব্যবহারকারীর timeline না বানানো (পর্ব ৫৬)। কখন উল্টো: লেখা পড়ার চেয়ে বেশি, বা follower-সংখ্যা সবার প্রায় সমান ও ছোট হলে pull সরল আর সস্তা। উত্তর: সাধারণভাবে push (≈ ৫৭,৮৭০ বনাম ≈ ৯,২৫,৯২৬ কাজ/s), তারকাদের জন্য pull — hybrid. ঝালাতে: পর্ব ৩২ আর ৫৬ (fan-out on write, fan-out on read).

sync : commit latency ~ 5 + 70 = 75 ms (15x slower writes); RPO = 0
async: commit ~ 5 ms; on region loss lose ~ lag x write rate
       typical: 0.2 s x 2,000 = 400 writes;  during a spike: 30 s x 2,000 = 60,000

সংখ্যা: sync প্রতিটি লেখায় ৭০ ms যোগ করে, আর দূরের region বিকল বা ধীর হলে লেখাই আটকে যায় (availability-র দাম, PACELC-এর “E”-তে latency বনাম consistency, পর্ব ৪০)। Async দ্রুত, কিন্তু region হারালে শত থেকে হাজার হাজার লেখা হারাতে পারে। সিদ্ধান্ত: payment ledger-এ টাকা হারানো চলে না — region-এর ভেতরে তিনটি zone-এ quorum বা sync commit (RPO শূন্য, latency মাত্র কয়েক ms), আর দূরের region-এ async কপি DR-এর জন্য। “Like”-এ কয়েক সেকেন্ডের ক্ষতি সহনীয় — async. কখন উল্টো: নিয়ম বা চুক্তিতে region-বিপর্যয়েও শূন্য ক্ষতি চাইলে দূরের sync-এর ৭০ ms মেনে নিতে হয়, আর লেখার থ্রুপুট রাখতে batching. উত্তর: ledger — কাছের sync বা quorum + দূরে async; like — async. ঝালাতে: পর্ব ২২, ৪০ আর ৫১।

logical writes = 50,000 x 100 B = 5 MB/s
B-tree  : 5 MB/s x 40 = 200 MB/s of disk writes
LSM-tree: 5 MB/s x 10 =  50 MB/s of disk writes (mostly sequential)
LSM point read: extra SSTable probes ~ 6 levels x 1% = 0.06 per lookup

সংখ্যা: (ধরে নেওয়া amplification-এ) LSM disk-এ চার গুণ কম লেখে, আর লেখে ক্রমিকভাবে — SSD-এর আয়ু আর throughput দুটিতেই লাভ। Bloom filter থাকায় একটি key খুঁজতে বাড়তি ফাইল-খোঁজা গড়ে মাত্র ০.০৬টি। কোথায় ভাঙে: compaction পেছনে disk আর CPU খায়, আর লেখার ঢেউয়ে পিছিয়ে পড়লে পড়া ধীর হয় আর জায়গা ফুলে ওঠে (space amplification); range scan-এ Bloom filter সাহায্য করে না। সিদ্ধান্ত: লেখা-ভারী, সময়-ক্রমিক ডেটায় LSM. কখন উল্টো: পড়া-ভারী, অনুমেয় latency আর জায়গায় বদলানো (update-in-place) লাগলে B-tree (পর্ব ১৯)। আসল amplification workload আর setting-ভেদে অনেক আলাদা — নিজের ডেটায় মাপুন। উত্তর: LSM-tree (≈ ৫০ বনাম ≈ ২০০ MB/s disk-লেখা)। ঝালাতে: পর্ব ১৯ (LSM-tree, write amplification).

limits at 70%: writes 10,500 /s, data 14 TB
years until writes hit it: log(10,500 / 8,000) / log(1.3) = 1.04 years
years until data hits it : log(14 / 8) / log(1.3)         = 2.13 years
-> the write rate runs out first, in about a year

সংখ্যা: বড় মেশিন (vertical scaling) প্রায় এক বছর সময় কেনে — লেখার হারই আগে ফুরায়, storage নয়। Read replica এখানে কিছুই করে না, কারণ লেখা শুধু primary-তে। সিদ্ধান্ত: আপাতত বড় মেশিনে যান — সরল, ঝুঁকি কম — কিন্তু আজই shard key বেছে sharding-এর কাজ শুরু করুন, কারণ data migration আর application বদলাতে মাস লাগে; ৯–১০ মাসে প্রস্তুত থাকা চাই (পর্ব ১৩ আর ২৩)। কখন উল্টো: বৃদ্ধি ১০০%/বছর হলে runway মাত্র log(১.৩১২৫) ÷ log ২ ≈ ০.৪ বছর — তখন সরাসরি sharding. যাচাই: ৮,০০০ × ১.৩ = ১০,৪০০ (এক বছরে), সীমা ১০,৫০০-এর প্রায় গায়ে — মেলে। উত্তর: আপাতত বড় মেশিন, প্রায় ১ বছরের runway (storage-এ ≈ ২.১ বছর); sharding-এর প্রস্তুতি এখনই। ঝালাতে: পর্ব ১৩ আর ২৩ (capacity planning).

z zones, survive 1: each of the remaining (z - 1) carries 30 / (z - 1)
z = 2: 30 per zone, total 60, extra 100%
z = 3: 15 per zone, total 45, extra  50%
z = 4: 10 per zone, total 40, extra  33%
general: total = N x z / (z - 1)

সংখ্যা: zone বাড়লে বাড়তি খরচ ১০০% থেকে ৩৩%-এ নামে। দাম: প্রতিটি zone-এ load balancer, database replica আর monitoring লাগে; zone-এর মধ্যে ডেটা পাঠানোয় latency আর (অনেক cloud-এ) খরচ যোগ হয়; quorum-ভিত্তিক database-এ ৩টি zone স্বাভাবিক মিল (৩-এর মধ্যে ২-এর majority). সিদ্ধান্ত: সাধারণত ৩টি — ৫০% বাড়তি, আর quorum-এর সাথে মানানসই। কখন উল্টো: ছোট সেবায় (৩–৪টি সার্ভার) ৪টি zone-এ ভাগ করলে প্রতিটিতে ১টি — একটি deploy-ও তখন zone হারানোর মতো; ২টি zone আর autoscaling সরল হতে পারে। উত্তর: ২ zone-এ ৬০টি (১০০%), ৩-এ ৪৫টি (৫০%), ৪-এ ৪০টি (≈ ৩৩%); সাধারণত ৩টি zone. ঝালাতে: পর্ব ০৫ আর ৫১ (overprovisioning).

(a) polling  : 10^6 / 10 s = 100,000 req/s x 800 B x 8 = 640 Mbit/s
               useful: 5,000 / 100,000 = 5% of polls carry news
    WebSocket: 10^6 open connections x 20 KB = 20 GB RAM; 5,000 msg/s pushed
               news arrives at once (not up to 10 s late)

সংখ্যা: polling-এ ৯৫% অনুরোধ খালি হাতে ফেরে, আর খবর গড়ে ৫ সেকেন্ড দেরিতে পৌঁছায়; WebSocket-এ অনুরোধ প্রায় ২০ গুণ কম, খবর সঙ্গে সঙ্গে — দাম ২০ GB RAM জুড়ে দীর্ঘজীবী সংযোগ, সেগুলো load balancer-এ ভাগ করা, deploy-এর সময় ১০ লাখ সংযোগের ধীরে পুনঃসংযোগ (না হলে thundering herd). সিদ্ধান্ত: chat বা live score-এর মতো ঘন ঘন, তাৎক্ষণিক খবরে WebSocket (বা এক দিকের হলে SSE). কখন উল্টো: খবর বিরল আর কয়েক মিনিট দেরি চলে (যেমন দিনে দুবার বদলানো তালিকা) — তখন সাধারণ HTTP polling, cache আর CDN সরল, সস্তা আর ভরসাযোগ্য (পর্ব ১০)। উত্তর: এখানে WebSocket (১,০০,০০০ req/s আর ৬৪০ Mbit/s-এর বদলে ৫,০০০ বার্তা/s আর ≈ ২০ GB RAM). ঝালাতে: পর্ব ১০ আর ৫৫।