লিখিত ও মৌখিক (ভাইভা) প্রশ্ন — scaling, storage, distributed systems আর architecture

সংজ্ঞা: Functional requirement বলে সিস্টেম কী করবে — এমন আচরণ, যা হ্যাঁ বা না দিয়ে যাচাই করা যায়। Non-functional requirement বলে কতটা ভালোভাবে — latency, availability, কতজন ব্যবহারকারী, খরচ, নিরাপত্তা — আর তা লিখতে হয় সংখ্যায়।

Availability বনাম durability: এক নয়। Availability মানে এই মুহূর্তে সেবা পাওয়া যায় কি না; durability মানে সংরক্ষিত ডেটা হারায় কি না। এক ঘণ্টার বিভ্রাটে সেবা বন্ধ, কিন্তু একটি লেখাও হারায়নি — availability কমেছে, durability অক্ষুণ্ণ।

নম্বর কোথায়: দুটি সংজ্ঞা (১), টেবিল বা দুই জোড়া উদাহরণ (২), availability বনাম durability (১)। পর্ব ০২ · পর্ব ০৫

যেখানে নম্বর কাটে: সংখ্যা ছাড়া NFR (“দ্রুত হবে”, “scalable হবে”); ACID-এর C আর CAP-এর C এক বলে লেখা।

সংজ্ঞা: latency = একটি অনুরোধের শুরু থেকে উত্তর পর্যন্ত সময় (ms); throughput = প্রতি সেকেন্ডে শেষ হওয়া কাজ (req/s); bandwidth = পথ সর্বোচ্চ কতটা বইতে পারে (Gbit/s).

Percentile: p99 মানে ১০০টি অনুরোধের ৯৯টি এর চেয়ে দ্রুত। গড় কয়েকটি খুব ধীর অনুরোধ লুকিয়ে ফেলে — সেই tail-ই ব্যবহারকারী টের পান। কয়েকটি সার্ভারের p99-এর গড় সেবার p99 নয় — histogram-এর bucket যোগ করে তারপর percentile.

Fan-out-এর হিসাব:

1. সূত্র: P(অন্তত একটি ধীর) = 1 − (1 − p)^N.
2. মান: 1 − 0.99⁵⁰ ≈ 1 − 0.605 = ০.৩৯৫, অর্থাৎ প্রায় ৩৯.৫%.

Little-এর সূত্র: L = λW = ২,০০০ × ০.১৫ = ৩০০টি অনুরোধ গড়ে একসাথে চলছে। Thread বা connection pool অন্তত এত, peak-এর জন্য আরও বাড়তি।

Trade-off: batching throughput বাড়ায় কিন্তু latency বাড়াতে পারে। ব্যস্ততা ρ বাড়লে M/M/1 মডেলে গড় সময় W = S ÷ (1 − ρ): S = ১০ ms ধরলে ρ = ০.৫-এ ২০ ms, ০.৯-এ ১০০ ms.

নম্বর কোথায়: তিন সংজ্ঞা (২), percentile-এর যুক্তি (২), fan-out সূত্র ও মান (৩), Little ও প্রয়োগ (২), utilisation বা প্রতিকার (১)। পর্ব ০৪ · পর্ব ৫০

যেখানে নম্বর কাটে: “৫০ × ১% = ৫০%” — সম্ভাবনা যোগ করা; ms-কে সেকেন্ড না করে L = ৩,০০,০০০ লেখা; percentile-এর গড় নেওয়া।

সূত্র: downtime = (১ − A) × ৫,২৫,৬০০ মিনিট (৩৬৫ দিনের বছর)। প্রতিটি বাড়তি nine downtime দশ ভাগের এক ভাগ করে।

Trade-off ও শর্ত: parallel-এর হিসাব ধরে নেয় ব্যর্থতা স্বাধীন; একই rack, একই config push বা সব কপিতে একই bug — correlated failure — হলে লাভ অনেক কম.

নম্বর কোথায়: downtime (২), series ও parallel (২), MTBF সূত্র (১), স্বাধীনতার শর্ত (১)। পর্ব ০৫

যেখানে নম্বর কাটে: parallel-এও availability গুণ করা; স্বাধীনতার শর্ত না লেখা; বছরের দিন-সংখ্যার প্রথা না বলা।

সংজ্ঞা: একটি অনুরোধ idempotent যদি একবার বা বহুবার পাঠালে সার্ভারের অবস্থা একই থাকে।

Retry নিরাপদ করা:

1. Client প্রতিটি লেনদেনের জন্য একটি এলোমেলো Idempotency-Key বানায়; retry-তে একই key.
2. সার্ভারে UNIQUE (client, key) সারি, সাথে body-র hash আর জমা উত্তর।
3. একই key আর একই body → আগের উত্তর আবার, টাকা কাটে একবারই; ভিন্ন body → 422; প্রথমটি এখনো চলছে → 409.

Trade-off: প্রতি অনুরোধে একটি বাড়তি লেখা; key-এর মেয়াদ ছোট হলে দেরির retry আবার চলে।

নম্বর কোথায়: সংজ্ঞা (১), টেবিল (২), key-এর নকশা (২)। পর্ব ০৮ · পর্ব ৩৪

যেখানে নম্বর কাটে: key সার্ভারে বানানো (তাহলে retry পায় নতুন key); body না মিলিয়ে আগের উত্তর ফেরত দেওয়া।

হিসাব: N ÷ I = ১,০০,০০০ ÷ ৫ = সেকেন্ডে ২০,০০০ অনুরোধ; খবর আসে দুই poll-এর মাঝে যেকোনো সময়ে, তাই গড় দেরি I/২ = ২.৫ সেকেন্ড.

Trade-off: স্থায়ী সংযোগ মানে stateful gateway, load balancer-এ দীর্ঘ বাঁধন আর gateway restart-এ reconnect-এর ঢল — প্রতিকার backoff আর full jitter. উপসংহার: স্কোর বা নোটিশের ধারায় SSE, chat-এ WebSocket, কদাচিৎ হালনাগাদে polling-ই যথেষ্ট।

নম্বর কোথায়: টেবিল (৩), হিসাব (১), trade-off (১)। পর্ব ১০

যেখানে নম্বর কাটে: SSE-কে দুই দিকের বলা; poll-এর গড় দেরি I ধরা।

সংজ্ঞা ও কাজ: একদল সার্ভারের সামনের প্রবেশপথ, চারটি কাজ — ভার ভাগ, health check দিয়ে বিকল সার্ভার লুকানো, একটিমাত্র ঠিকানা (virtual IP), আর সেবা না থামিয়ে deploy (draining).

ছবি (খাতায়): client → virtual IP → LB জোড়া (active আর standby, মাঝে heartbeat) → তিনটি সার্ভার; একটিতে ক্রস চিহ্ন, LB থেকে প্রতিটি সার্ভারে health check-এর ড্যাশ দাগ।

Algorithm: round robin — সার্ভার আর অনুরোধ সমান হলে; weighted — ক্ষমতা বিষম হলে; least connections — অনুরোধের সময় বিষম হলে; power of two choices — দুটি এলোমেলো বেছে কম ব্যস্তটি, অনেক LB আর পুরোনো তথ্যেও ভিড় জমায় না; consistent hashing — একই key একই সার্ভারে দরকার হলে।

হিসাব: ধরা পড়ার সবচেয়ে খারাপ সময় ≈ fall × interval + timeout = ২ × ৫ + ২ = ১২ সেকেন্ড; ততক্ষণে প্রায় ১২ × ৩০০ = ৩,৬০০টি অনুরোধ ব্যর্থ হতে পারে।

LB নিজেই SPOF? active-passive-এ VRRP দিয়ে virtual IP সরে; active-active-এ anycast আর ECMP.

নম্বর কোথায়: চার কাজ (১), ছবি (২), টেবিল (৩), algorithm (২), হিসাব (১), SPOF (১)। পর্ব ১৪ · পর্ব ১১

যেখানে নম্বর কাটে: হিসাবে timeout বাদ দেওয়া; L7-কে “শুধু বেশি দ্রুত” বলা; LB-কে single point of failure হিসেবে না দেখা।

সমস্যা: N থেকে N + 1 করলে N/(N + 1) ভাগ key সরে। কারণ: প্রতি N(N + 1)টি পরপর মানে k mod N আর k mod (N + 1) সমান হয় মাত্র N টিতে, তাই থাকে 1/(N + 1). ৪ → ৫-এ ৪/৫ = ৮০%, অর্থাৎ ৮০ লাখ key.

Consistent hashing: hash-এর পরিসরকে একটি বৃত্ত (ring) ধরা হয়; সার্ভার আর key একই hash-এ ring-এ বসে; key যায় ঘড়ির কাঁটার দিকে পরের সার্ভারে। নতুন সার্ভার শুধু তার ঠিক আগের অংশটুকু নেয়: গড়ে K/(N + 1) = ১ কোটি ÷ ৫ = ২০ লাখ key (২০%) — নতুন সার্ভারের ন্যায্য ভাগ, এর কম সরিয়ে কাজ হয় না।

ছবি (খাতায়): একটি বৃত্তে চারটি বিন্দু A, B, C, D; B আর C-র মাঝে নতুন E; B থেকে E পর্যন্ত বৃত্তাংশ দাগানো — “শুধু এই key-গুলো C থেকে E-তে যায়”; কয়েকটি key থেকে ঘড়ির কাঁটার দিকে তীর।

Virtual node: অল্প সার্ভারে ring-এর ভাগ খুব অসম। প্রতিটি সার্ভারকে V জায়গায় বসালে ভাগের ছড়ানো মোটামুটি 1/√V — V = ১০০-তে প্রায় ১০%. দাম: ring-এ N·V বিন্দু, lookup O(log(N·V)).

সীমা ও উপসংহার: এটি key-এর সংখ্যা সমান করে, চাপ নয় — একটি hot key তবু একটি সার্ভারেই পড়ে; তার প্রতিকার আলাদা (local cache, কপি)।

নম্বর কোথায়: mod N-এর সমস্যা ও ভাগ (২), ring-এর ছবি (২), সরার হিসাব (২), virtual node (২), তুলনা বা সীমা (২)। পর্ব ১৬ · পর্ব ৩০

যেখানে নম্বর কাটে: “consistent hashing-এ কোনো key সরে না”; ছবিতে দিক না দেখানো; hot key সারাতে V বাড়ানোর কথা বলা।

সংজ্ঞা: throughput = শেষ হওয়া কাজ; goodput = তার মধ্যে সময়মতো, কাজে লাগা উত্তর। Overload-এ প্রথমটি সর্বোচ্চ থাকলেও দ্বিতীয়টি শূন্যের দিকে নামতে পারে।

1. Queue বাড়ে λ − μ = সেকেন্ডে ১০০টি করে।
2. নতুন অনুরোধের অপেক্ষা = Q ÷ μ; এটি D = ৩ সেকেন্ড ছাড়ায় যখন Q > D·μ = ১,২০০.
3. সময় t = D·μ ÷ (λ − μ) = ৩ × ৪০০ ÷ ১০০ = ১২ সেকেন্ড. তারপর সার্ভার পুরো ব্যস্ত, অথচ প্রতিটি উত্তর client ছেড়ে যাওয়ার পরে — goodput প্রায় শূন্য; retry এলে λ আরও বাড়ে।

প্রতিকার: bounded queue আর দ্রুত 503 বা 429 (fail fast); ভেতরের অংশে backpressure — উৎসকে ধীর করা (bounded channel, TCP flow control); দরজায় load shedding — অগ্রাধিকার বুঝে বাড়তি কাজ ফেরানো; মেয়াদ পেরোনো কাজ বাদ; retry budget; কম দিয়ে হলেও চালু থাকা (graceful degradation).

নম্বর কোথায়: দুই সংজ্ঞা (১), হিসাব ও যুক্তি (৩), প্রতিকার (২)। পর্ব ১৮ · পর্ব ৪৮

যেখানে নম্বর কাটে: “autoscaling করব” — তা কয়েক মিনিট দেরিতে আসে; exponential backoff-কেই যথেষ্ট বলা — টানা overload-এ মোট চেষ্টা কমে না।

WAL: যেকোনো বদল আগে log-এর শেষে যোগ আর fsync, তারপর আসল কাঠামোয়। Crash হলে log থেকে আবার চালানো (redo).

B+-tree: প্রতিটি node একটি page; leaf জায়গায় বদলায়। ৫০০ × ৫০০ × ৫০০ = ১২.৫ কোটি key তিন স্তরে — যেকোনো key-এ প্রায় ৩টি page, ওপরের স্তর RAM-এ থাকলে আরও কম।

LSM-tree: লেখা যায় RAM-এর memtable-এ → ভরলে সাজানো SSTable ফাইল ডিস্কে → পেছনে compaction মেলায়। পড়ায় কয়েক স্তর দেখতে হয়; Bloom filter অপ্রয়োজনীয় ফাইল বাদ দেয়।

Trade-off ও উপসংহার: read, update আর memory-র খরচ একসাথে কমানো যায় না (RUM). পড়া-ভারী লেনদেন আর range query-তে B+-tree; লেখা-ভারী log, metric বা time-series-এ LSM.

নম্বর কোথায়: WAL (২), দুই কাঠামো (৩), হিসাব (১), টেবিল (৩), বাছাই (১)। পর্ব ১৯ · পর্ব ২১

যেখানে নম্বর কাটে: compaction-এর দাম না বলা; WAL-কে backup বলা।

সংজ্ঞা: একই ডেটার কয়েকটি জীবন্ত কপি। Single-leader-এ সব লেখা leader-এ যায়; leader তার log (WAL বা সারিভিত্তিক) follower-দের পাঠায়; পড়া follower থেকেও হয়। লাভ: availability, পড়া ভাগ, কাছের কপি, durability. Replication পড়া বাড়ায়, লেখা নয়।

ছবি (খাতায়): client-এর লেখা → Leader (সিলিন্ডার) → ড্যাশ তীরে Follower ১ আর ২; পড়ার তীর follower-এ; follower-এর পাশে “lag Δt”.

Lag-এর তিন সমস্যা:

1. নিজের লেখা উধাও → read-your-writes: নিজের ডেটা leader থেকে, বা লেখার অবস্থান (LSN) পর্যন্ত পৌঁছানো replica থেকে।
2. সময় পেছনে যাওয়া (প্রথমবার নতুন, পরে পুরোনো) → monotonic reads: একজন ব্যবহারকারীকে এক replica-তে বাঁধা।
3. প্রশ্নের আগে উত্তর → consistent prefix: সম্পর্কিত লেখা একই partition-এ, একই ক্রমে।

Failover-এর ভুল: async-এ হারানো লেখা; পুরোনো leader ফিরে এসে লিখলে split-brain (প্রতিকার fencing বা epoch); ভুল timeout-এ অকারণ failover.

নম্বর কোথায়: সংজ্ঞা ও ছবি (২), তিন মোড (৩), lag-এর তিন সমস্যা (৩), failover (২)। পর্ব ২২ · পর্ব ৫১ · পর্ব ৪৩

যেখানে নম্বর কাটে: replication-কে backup বলা (ভুল DELETE-ও কপি হয়); “sync হলে সব সমস্যা শেষ” — দামের কথা না বলা।

পার্থক্য: partitioning ডেটা ভাগ করে ক্ষমতা (বিশেষ করে লেখা) বাড়ায়; replication কপি রাখে টিকে থাকা আর পড়ার জন্য। বাস্তবে দুটো একসাথে — প্রতিটি shard-এর তিনটি কপি।

Shard key-এর চার শর্ত: অনেক ভিন্ন মান; সমান ছড়ানো; ঘন query-র ডেটা এক shard-এ; বৃদ্ধির সাথেও টেকে। পরে বদলানো খুব দামি।

Rebalancing: node-এর চেয়ে অনেক বেশি নির্দিষ্ট partition বানিয়ে পুরো partition সরানো। ৫টি node-এ ন্যায্য ভাগ ২৫৬ ÷ ৫ = ৫১.২, তাই নতুন node অন্যদের থেকে ৫১টি partition নেয় — প্রায় ২০%; hash mod N-এ সরত প্রায় ৮০% key.

Snowflake-ধাঁচের ID: ১ চিহ্ন-bit + ৪১-bit millisecond timestamp + ১০-bit worker + ১২-bit sequence.

1. প্রতি worker প্রতি ms-এ ২^১২ = ৪,০৯৬টি ID; worker ২^১০ = ১,০২৪টি।
2. আয়ু ২^৪১ ms ≈ ৬৯.৭ বছর, নিজের বেছে নেওয়া epoch থেকে।

নম্বর কোথায়: পার্থক্য (১), শর্ত (২), টেবিল (২), rebalancing (২), ID-র নকশা ও হিসাব (৩)। পর্ব ২৩ · পর্ব ১৬

যেখানে নম্বর কাটে: hot key ভুলে যাওয়া; ID-র আয়ু “চিরকাল” বলা; worker ID কে, কীভাবে পাবে তা না ভাবা।

ACID: A — ব্যর্থ হলে সব বা কিছুই না; C — অ্যাপের নিয়ম (invariant) রক্ষা, CAP-এর C নয়; I — একসাথে চলা কাজ একে অপরকে কতটা দেখে; D — commit-এর পরে crash-এও টেকে।

Anomaly:

• Dirty read — অন্যের commit-না-হওয়া বদল পড়া; পরে rollback হলে ভুল তথ্যে সিদ্ধান্ত।
• Lost update — balance ৫০০; দুজন একসাথে পড়েন; একজন ৩০০ তুলে ২০০ লেখেন, অন্যজন ৪০০ তুলে ১০০ লেখেন। প্রথম লেখা হারাল, অথচ ৫০০ টাকার ওয়ালেট থেকে বেরোল ৭০০।
• Read skew — দুটি অ্যাকাউন্ট আলাদা মুহূর্তে পড়ায় রিপোর্টে এমন মোট, যা কখনো ছিল না।
• Write skew — “অন্তত একজন on-call থাকবেন” দেখে দুজন ডাক্তার একসাথে ছুটি নেন; দুজনই আলাদা সারি লেখেন।

নামের ফাঁদ: PostgreSQL-এর REPEATABLE READ আসলে snapshot isolation, আর MySQL InnoDB-এর একই নামের level আলাদা আচরণ করে — নাম নয়, আচরণ যাচাই করুন।

ওয়ালেটের প্রতিকার: (১) শর্তসহ atomic লেখা — UPDATE wallet SET bal = bal - 300 WHERE id = 7 AND bal >= 300; ০ সারি মানে টাকা নেই। (২) SELECT … FOR UPDATE. (৩) version কলামে optimistic লেখা। (৪) SERIALIZABLE আর retry.

নম্বর কোথায়: ACID (২), চার anomaly (৩), টেবিল (৩), প্রতিকার (২)। পর্ব ২৪ · DBMS কোর্সে MVCC

যেখানে নম্বর কাটে: ACID-এর C-কে CAP-এর C বলা; SERIALIZABLE-এ abort আর retry-র কথা না বলা।

2PC:

1. Prepare: coordinator সবাইকে PREPARE পাঠায়; প্রত্যেকে কাজ করে, lock ধরে, PREPARED record ডিস্কে force করে YES (বা NO) বলে।
2. Commit: সব YES হলে coordinator COMMIT record force করে — এটিই commit point, এর পরে আর abort নেই; তারপর সবাইকে COMMIT, তারা force করে ack দেয়। একটি NO বা timeout হলে ABORT.

ছবি (খাতায়): চারটি খাড়া সময়রেখা C, P1, P2, P3; PREPARE-এর তীর ডানে, YES বাঁয়ে; C-র রেখায় তারা চিহ্ন “COMMIT force”; তারপর COMMIT আর ACK.

হিসাব: commit point = r + ২f = ১ + ৮ = ৯ ms (এক RTT, participant-এর PREPARED fsync আর coordinator-এর COMMIT fsync); পুরো প্রোটোকল ২r + ৩f = ২ + ১২ = ১৪ ms. বার্তা ৪N = ১২টি; forced write ২N + ১ = ৭টি.

Blocking: coordinator মরলে PREPARED participant নিজে সিদ্ধান্ত নিতে পারে না — lock ধরে অপেক্ষা করে। বাস্তবের প্রতিকার coordinator-এর সিদ্ধান্ত Raft বা Paxos দিয়ে replicated রাখা।

Saga: local transaction-এর শিকল, প্রতিটির একটি compensation; ব্যবসায়িক ব্যর্থতায় উল্টো ক্রমে compensation (টিকিট বাতিল → টাকা ফেরত), ক্ষণিকের ত্রুটিতে retry. Isolation নেই, তাই “pending” অবস্থা লাগে।

Outbox: database-এ লেখা আর broker-এ publish (dual write) মাঝপথে ভাঙে। Event একই local transaction-এ outbox টেবিলে, relay পরে পাঠায় — হারায় না, তবে দুবার যেতে পারে, তাই consumer idempotent.

নম্বর কোথায়: দুই ধাপ ও ছবি (৩), commit point ও blocking (২), হিসাব (২), saga ও outbox (৩)। পর্ব ২৫ · পর্ব ৩৪

যেখানে নম্বর কাটে: 2PC-কে consensus বলা; compensation-এর ক্রম উল্টো না রাখা; outbox-কে exactly-once বলা।

হিসাব: গড় = t_c + (১ − h) × t_db (miss-এও cache দেখার সময় যোগ হয়)। h = ০.৮: ০.৫ + ০.২ × ১০ = ২.৫ ms; h = ০.৯৫: ০.৫ + ০.০৫ × ১০ = ১.০ ms. Database-এর চাপ R(১ − h): সেকেন্ডে ২,০০০ থেকে ৫০০ — চার গুণ কম।

Delete কেন: delete idempotent আর ক্রম-নিরপেক্ষ, retry নিরাপদ; দুই লেখকের update উল্টো ক্রমে পৌঁছালে cache-এ পুরোনো মান থেকে যায়। তবু একটি race থাকে: পুরোনো মান পড়ে রাখা পাঠক লেখকের delete-এর পরে সেটি বসালে cache ভুল — প্রতিকার COMMIT-এর পরে delete, প্রতিটি key-এ TTL, আর lease বা version.

নম্বর কোথায়: টেবিল (৪), হিসাব (২), delete ও race (৪)। পর্ব ২৮

যেখানে নম্বর কাটে: miss-এ cache-এর সময় বাদ দেওয়া; write-behind-এর ক্ষতির জানালা না বলা।

LRU-এর কাঠামো: hash map (key → list-এর node) + doubly linked list (মাথায় সবচেয়ে সাম্প্রতিক, লেজে সবচেয়ে পুরোনো)।

1. get: map-এ node খোঁজা, list থেকে খুলে মাথায় বসানো — O(1).
2. put: নতুন node মাথায়; ভরা হলে লেজের node মোছা, map থেকেও — O(1).
3. Doubly কেন: মাঝের node খুলতে আগের node লাগে।

দুর্বলতা: একবার-পড়া বড় scan LRU-কে ধুয়ে দেয় — তখন SLRU, ARC বা W-TinyLFU.

Jitter: একসাথে মেয়াদ মানে এক সেকেন্ডে ১ লাখ miss (avalanche). ±১০%-এ মেয়াদ ৩,২৪০ থেকে ৩,৯৬০ সেকেন্ডে, ৭২০ সেকেন্ডের জানালায় ছড়ায় — গড়ে সেকেন্ডে প্রায় ১৩৯টি।

নম্বর কোথায়: কাঠামো ও O(1)-এর যুক্তি (৩), jitter ও হিসাব (২)। পর্ব ২৯

যেখানে নম্বর কাটে: শুধু linked list (তাহলে খোঁজা O(n)); singly linked list বলা।

হিসাব: আবার আনার সময়ে আসা অনুরোধ = ৫,০০০ × ০.০৪ = ২০০টি একই query.

নম্বর কোথায়: তিন সংজ্ঞা (২), হিসাব (১), প্রতিকার (২)। পর্ব ২৯ · পর্ব ০৬

যেখানে নম্বর কাটে: তিনটিকে এক বলা; Bloom filter-কে stampede-এর প্রতিকার বলা।

সূত্র: স্বাভাবিকে database-এ R(১ − h). একটি shard বিকল হলে তার ভাগ R/N-এর আগের hit-গুলোও miss: নতুন চাপ = R(১ − h) + (R/N)·h. অনুপাত = ১ + h ÷ (N(১ − h)) = ১ + ০.৯৬ ÷ (৮ × ০.০৪) = ১ + ৩ = ৪ গুণ.

তিন উপায়: প্রতিটি shard-এর replica আর দ্রুত failover; gutter pool — বিকল shard-এর key সাময়িক একটি ছোট pool-এ অল্প TTL-এ; database-এর সামনে concurrency সীমা আর request coalescing.

Hot key: sampling বা top-k দিয়ে চেনা; অল্প TTL-এর L1 (app-এর memory-তে); কয়েকটি shard-এ কপি (key#1 … key#k); coalescing. Virtual node বাড়িয়ে লাভ নেই — একটি key ভাগ হয় না।

নম্বর কোথায়: সূত্র ও মান (২), তিন উপায় (২), hot key (১)। পর্ব ৩০

যেখানে নম্বর কাটে: “চাপ ১/N বাড়ে” — hit ratio-র প্রভাব ভুলে যাওয়া।

হিসাব: delivery = E × N = ৫০০ × ৬ = সেকেন্ডে ৩,০০০; × ১ KB = বাইরে যায় সেকেন্ডে প্রায় ৩ MB. Fan-out গুণফলে বাড়ে — subscription দ্বিগুণ মানে খরচও দ্বিগুণ।

Consumer group: একটি group-এ প্রতিটি partition ঠিক একজন consumer পড়েন — ১২ জন কাজ করেন, ৪ জন অলস। সমান্তরালতার ছাদ partition-এর সংখ্যা; কেউ এলে বা গেলে rebalance. যাদের ক্রম জরুরি, তাদের একই key দিন — একই partition-এ যাবে।

লাভ ও দাম: producer আর consumer সময়, গতি আর ব্যর্থতায় আলাদা; ভিড় শোষণ (load levelling). দাম — eventual consistency, duplicate, ক্রম আর debugging.

নম্বর কোথায়: টেবিল (৪), হিসাব (২), consumer group (২), লাভ-দাম (২)। পর্ব ৩১ · পর্ব ৩২ · পর্ব ৩৩

যেখানে নম্বর কাটে: “Kafka পুরো topic-এ ক্রম দেয়”; partition না বাড়িয়ে consumer বাড়ালেই throughput বাড়বে বলা।

মূল সত্য: timeout মানে “জানি না” — বার্তা হারাল, নাকি কাজ হয়ে শুধু ack হারাল, প্রেরক আলাদা করতে পারে না।

কেন অসম্ভব: ack না এলে প্রেরকের সামনে দুটিই পথ — আবার পাঠানো (duplicate-এর ঝুঁকি) বা না পাঠানো (হারানোর ঝুঁকি); অজানা অবস্থা থেকে বেরোনোর তৃতীয় পথ নেই। তাই “exactly-once” বাস্তবে মানে প্রভাব একবার।

Effectively-once-এর ধাপ:

1. প্রতিটি বার্তায় একটি অনন্য id.
2. Consumer effect আর “দেখা হয়েছে” চিহ্ন (inbox টেবিল বা offset) একই local transaction-এ লেখে।
3. Duplicate এলে চিহ্ন দেখে বাদ।
4. বাইরের সেবায় (payment, email) তাদের নিজস্ব idempotency key.

Offset commit: আগে করলে crash-এ বার্তা হারায় (at-most-once); পরে করলে কয়েকটি দুবার আসে (at-least-once).

হিসাব: ২,০০০ × ৮৬,৪০০ × ৪০ byte = ৬.৯১ × ১০^৯ byte ≈ ৬.৯ GB. Window ছোট হলে পুরোনো duplicate (redrive, replay) ঢুকে পড়ে; বিকল্প per-producer sequence number — অনেক সস্তা।

নম্বর কোথায়: টেবিল (৩), অসম্ভবতার যুক্তি (২), effectively-once (২), offset (১), হিসাব (২)। পর্ব ৩৪ · পর্ব ৩৩

যেখানে নম্বর কাটে: “broker exactly-once দেয়, তাই চিন্তা নেই”; dedup window-এর আকার যুক্তি ছাড়া।

Event sourcing: শুধু বর্তমান অবস্থা নয়, প্রতিটি ঘটনা রাখা; অবস্থা = ঘটনাগুলোর fold — মুদি দোকানের খাতার মতো, শেষ লাইনের বাকি নয়, প্রতিটি লেনদেন। Event store শুধু যোগ করে; লেখায় “আমি version ৪ দেখে লিখছি” — optimistic concurrency.

CQRS: লেখার মডেল (নিয়ম যাচাই) আর পড়ার মডেল (প্রতিটি পাতার মাপে সাজানো) আলাদা; projector event পড়ে read model বানায়, যা একটু পিছিয়ে থাকে।

এক নয়: event sourcing ছাড়া CQRS আর CQRS ছাড়া event sourcing — দুটোই সম্ভব।

হিসাব: শেষ snapshot version ২,০০০-এ (৫০০-এর গুণিতক); বাকি ২,৩৪০ − ২,০০০ = ৩৪০টি event replay.

Trade-off: লাভ audit, অতীতের যেকোনো মুহূর্তে ফেরা আর নতুন read model; দাম জটিলতা, event-এর schema চিরকাল বহন (upcasting) আর মুছে ফেলার কঠিন প্রশ্ন। বেশিরভাগ CRUD অংশে লাগে না।

নম্বর কোথায়: দুই সংজ্ঞা (২), পার্থক্য (১), হিসাব (১), trade-off (১)। পর্ব ৩৫

যেখানে নম্বর কাটে: দুটিকে সমার্থক বলা; read model তাৎক্ষণিক ধরে নেওয়া।

পার্থক্য: batch সীমিত (bounded) ডেটায় কাজ করে — গতকালের সব log; দাম দেরি। Stream অসীম (unbounded) ধারায় — যা এখনো আসছে; দাম অসম্পূর্ণতা।

দুই সময়: event time = ঘটনা কখন ঘটেছে (ফোনের timestamp); processing time = processor কখন দেখল। নেটওয়ার্কহীন ফোন পরে পাঠালে দুটি অনেক আলাদা; ব্যবসার প্রশ্নে event time.

Watermark: processor-এর অনুমান — “এর চেয়ে পুরোনো ঘটনা আর আসবে না”; তখন window-এর ফল দেওয়া হয়। উদাহরণ: ১০:০০–১০:০১-এর window; watermark ১০:০১ পেরোলে প্রথম ফল; allowed lateness ২ মিনিট হলে watermark ১০:০৩ পেরোনো পর্যন্ত দেরির ঘটনা ফল সংশোধন করে (sink-এ upsert); তারপর আলাদা পথে (side output) বা বাদ।

নম্বর কোথায়: পার্থক্য (১), দুই সময় (১), watermark ও lateness (২), উদাহরণ (১)। পর্ব ৩৬

যেখানে নম্বর কাটে: watermark-কে নিশ্চয়তা বলা — এটি অনুমান; processing time ধরে ব্যবসার হিসাব।

Partial failure: কিছু অংশ চলে, কিছু থামে, আর একটি call-এর ফল অজানা থাকতে পারে; এক যন্ত্রে সাধারণত সব বা কিছুই না।

Timeout: request হারানো, reply হারানো আর ধীর node — বাইরে থেকে তিনটি এক। বলা যায় শুধু “উত্তর আসেনি”; কাজ হয়েছে কি না অজানা — তাই retry কেবল idempotent কাজে।

ডেটা সেন্টারের বেশিরভাগ সিস্টেম ধরে partial synchrony আর crash-recovery (system model).

৩ | ২ partition: majority (৩) পক্ষ এগোয়; ২-এর পক্ষ থামে — নইলে দুই পক্ষই লিখে split-brain.

নম্বর কোথায়: partial failure (১), timeout (১), model (২), partition (১)। পর্ব ৩৮

যেখানে নম্বর কাটে: “timeout মানে node মৃত”।

Wall clock-এর সমস্যা: quartz ঘড়ি সরে (২০ ppm মানে দিনে প্রায় ১.৭ সেকেন্ড), NTP-র পরে লাফায়। ঘড়ির পার্থক্যের চেয়ে কাছাকাছি দুটি ঘটনা উল্টো ক্রমে দেখা যায়।

Lamport-এর নিয়ম: প্রতিটি ঘটনায় L = L + ১; পাঠানোর সময় L সাথে যায়; গ্রহণে L = max(L, L_{বার্তা}) + ১. গুণ: a → b হলে L(a) < L(b); উল্টোটা সত্য নয়।

Vector-এর নিয়ম: প্রতিটি process-এর একটি ঘর; নিজের ঘটনায় নিজের ঘর + ১; পাঠানোয় পুরো vector যায়; গ্রহণে ঘর ধরে max, তারপর নিজের ঘর + ১. সব ঘরে ≤ আর অন্তত একটিতে < হলে আগে; নইলে concurrent.

ছবি (খাতায়): তিনটি আনুভূমিক সময়রেখা P1, P2, P3; b থেকে d-তে আর e থেকে g-তে তির্যক তীর; প্রতিটি বিন্দুর পাশে L আর vector.

b ও c: L(c) = ১ < L(b) = ২, তবু c → b নয়। Vector [0,1,0] আর [2,0,0] — একটির প্রথম ঘর বড়, অন্যটির দ্বিতীয় — তাই concurrent. Lamport একটি ক্রম দেয়, কিন্তু concurrency চেনে না।

নম্বর কোথায়: wall clock-এর সমস্যা (১), দুই নিয়ম (২), ছবি (২), টেবিল (৩), সম্পর্ক ও সীমা (২)। পর্ব ৩৯ · পর্ব ৪৬

যেখানে নম্বর কাটে: গ্রহণের পরে + ১ ভুলে যাওয়া; Lamport-এর মান দেখে concurrency নিয়ে দাবি।

Serializability বনাম linearizability: এক নয়। প্রথমটি বহু object-এর transaction — ফল কোনো একটি ক্রমিক ক্রমের মতো, যেকোনো ক্রম; দ্বিতীয়টি একটি object-এর বাস্তব সময়ের ক্রম। দুটি একসাথে strict serializability.

নম্বর কোথায়: চার মডেল (৩), পার্থক্য (২)। পর্ব ৪০ · পর্ব ২৪

যেখানে নম্বর কাটে: “eventual মানে কয়েক সেকেন্ডে নিশ্চিত”; sequential আর linearizable এক বলা।

প্রমাণ: লেখা পৌঁছায় W টি replica-র সেট S_W-এ, পড়া উত্তর নেয় R টির সেট S_R থেকে। |S_W ∪ S_R| ≤ N, তাই |S_W ∩ S_R| = W + R − |S_W ∪ S_R| ≥ W + R − N ≥ ১. সেই অন্তত একটি replica সর্বশেষ সম্পন্ন লেখা রাখে, আর পড়া সব উত্তরের মধ্যে সবচেয়ে নতুন version নেয়। ∎

Quorum তবু ঠকায়:

1. চলমান লেখা: কিছু replica নতুন, কিছু পুরোনো — পরপর দুটি পড়া উল্টো ফল দেখতে পারে।
2. ব্যর্থ আংশিক লেখা: W পূরণ হয়নি, কিন্তু যেখানে পৌঁছেছে সেখানে থেকে যায় — rollback নেই।
3. Sloppy quorum: নিজের তালিকার বাইরের node-এর ack W-এ গোনা — overlap হারায়।
4. Concurrent লেখা আর LWW: একটি নিঃশব্দে হারায়।

Linearizable পড়া-লেখা দরকার হলে উত্তর ফেরানোর আগে blocking read repair (তবু compare-and-set-এ নয়), নয়তো consensus.

মেরামত: read repair — পড়ায় পুরোনো replica পেলে নতুন মান লিখে দেওয়া; hinted handoff — বন্ধ replica-র লেখা আরেকজন “hint”-সহ রেখে পরে পৌঁছে দেয়; anti-entropy — Merkle tree দিয়ে পেছনে মিলানো।

নম্বর কোথায়: প্রমাণ (৩), টেবিল (২), তিন ক্ষেত্র (৩), মেরামত (২)। পর্ব ৪১ · পর্ব ৬১

যেখানে নম্বর কাটে: প্রমাণের জায়গায় শুধু উদাহরণ; “R + W > N মানেই linearizable”.

সংজ্ঞা: Consensus মানে কয়েকটি সার্ভারের একটি log-এর ক্রমে একমত হওয়া — agreement, validity আর termination.

State diagram (খাতায়): তিনটি বৃত্ত — follower → (timeout) → candidate → (majority ভোট) → leader; candidate থেকে follower-এ তীর “বড় term বা বৈধ leader দেখলে”; leader থেকে follower-এ “বড় term দেখলে”।

Election:

1. Follower নির্দিষ্ট সময়ে heartbeat না পেলে term + ১ করে, নিজে ভোট দেয়, সবাইকে RequestVote পাঠায়।
2. প্রতি term-এ প্রত্যেকে একটিই ভোট দেয় — শুধু সেই candidate-কে, যার log অন্তত ভোটদাতার মতো হালনাগাদ (আগে শেষ entry-র term, তারপর দৈর্ঘ্য)।
3. Majority পেলে leader. Election timeout এলোমেলো (Raft paper-এর উদাহরণে ১৫০–৩০০ ms), যাতে সবাই একসাথে candidate হয়ে ভোট ভাগ (split vote) না করে।

Log replication: client-এর command leader-এর log-এ; AppendEntries-এ prevLogIndex আর prevLogTerm — না মিললে follower প্রত্যাখ্যান করে, leader পেছনে গিয়ে মেলায়। Entry majority-তে পৌঁছালে committed, তারপর state machine-এ প্রয়োগ আর client-কে উত্তর। Leader কপি গুনে commit করে শুধু নিজের term-এর entry; আগেরগুলো তার সাথে পরোক্ষে।

সহনশীলতা: ২f + ১টি সার্ভার f টি crash সয়। ৫ → majority ৩, সয় ২টি; ৪ → majority ৩, সয় মাত্র ১টি — জোড় সংখ্যায় লাভ নেই। যেকোনো দুটি majority অন্তত একজনে মেলে, তাই committed entry নতুন leader-এর চোখ এড়ায় না।

নম্বর কোথায়: state diagram (২), election (৩), replication ও commit (৩), সহনশীলতা (২)। পর্ব ৪২

যেখানে নম্বর কাটে: “৪টিতে ২টি সয়”; split vote-এর কারণ না বলা; আগের term-এর entry কপি গুনেই commit বলা।

Timeline (খাতায় দুটি সময়রেখা, client A আর B, নিচে storage):

1. A lock পায়, token ৩৩, lease ১০ সেকেন্ড।
2. A-র process GC-বিরতিতে ১৫ সেকেন্ড থেমে থাকে — নিজে জানে না।
3. Lease ফুরায়; B lock পায়, token ৩৪, storage-এ লেখে।
4. A জেগে নিজেকে এখনো ধারক ভেবে token ৩৩ নিয়ে লেখে।
5. Storage আগেই ৩৪ দেখেছে; ৩৩ < ৩৪ → প্রত্যাখ্যান।

শর্ত: fencing token একঘেয়েভাবে বাড়তে থাকা নম্বর (UUID নয় — তাতে ছোট-বড় নেই), আর যাচাই করে storage নিজে, lock সেবা নয়।

বিকল্প: অনেক সময় lock-ই লাগে না — শর্তসহ লেখা (compare-and-set, version), idempotency, বা প্রতিটি key-এর একজনই লেখক।

নম্বর কোথায়: সমস্যার কারণ (১), timeline (২), শর্ত (১), বিকল্প (১)। পর্ব ৪৩

যেখানে নম্বর কাটে: “TTL বাড়ালেই হবে”; যাচাই lock সেবায় বলা।

কাজ: Bloom filter-এ m bit-এর array আর k টি hash. যোগ: k টি bit ১; খোঁজ: k টির সব ১ হলে “হয়তো আছে”, একটি ০ হলেও “নিশ্চিত নেই”।

সূত্র: n টি key আর k টি hash-এর পরে একটি bit ০ থাকার সম্ভাবনা ≈ e^−kn/m; false positive p ≈ (১ − e^−kn/m)^k. সেরা k = (m/n) ln 2 — তখন অর্ধেক bit ১, আর m/n = −ln p ÷ (ln 2)².

হিসাব: p = ০.০১ → m/n ≈ ৯.৫৯ bit; m ≈ ৯.৫৯ × ১০^৭ bit ≈ ১২ MB; k ≈ ৯.৫৯ × ০.৬৯৩ ≈ ৬.৬৪ → ৭টি hash. (০.১%-এ প্রায় ১৪.৪ bit আর ১০টি hash.)

ভুলের দিক: শুধু false positive; false negative নেই, যদি মোছা না হয়। মুছতে হলে counting Bloom বা cuckoo filter. নিরাপদ জায়গা: LSM-এ অপ্রয়োজনীয় SSTable বাদ, cache penetration ঠেকানো — ভুল মানে সামান্য বাড়তি কাজ। চূড়ান্ত সিদ্ধান্তে (বিল, duplicate বাদ) নয়।

নম্বর কোথায়: কাজ (১), সূত্র ও k (২), হিসাব (২), ভুলের দিক ও ব্যবহার (১)। পর্ব ৪৫ · পর্ব ১৯

যেখানে নম্বর কাটে: bit-কে byte ধরে প্রায় ৯৬ MB লেখা; false negative আছে বলা।

সংজ্ঞা: Monolith — পুরো অ্যাপ একটি প্রোগ্রাম, একসাথে deploy. Microservices-এর দুটি সংজ্ঞাগত শর্ত: প্রতিটি সেবা আলাদাভাবে deploy করা যায়, আর নিজের ডেটার একমাত্র মালিক।

হিসাব: ০.৯৯৯^১৫ ≈ ৯৮.৫১% — বছরে প্রায় ১৩০ ঘণ্টা কোনো না কোনো সেবা বিকল।

Boundary: ব্যবসার ভাষায় — bounded context আর aggregate (অর্ডার, পেমেন্ট, ক্যাটালগ); টেবিল বা কোডের স্তর (controller, DAO) দিয়ে নয়। যা একসাথে বদলায়, তা একসাথে থাকে।

Distributed monolith-এর চিহ্ন: একটি অনুরোধে ডজনখানেক বাচাল call; কয়েক সেবা একই টেবিলে লেখে; সবাইকে একসাথে deploy করতে হয়।

উপসংহার: নতুন সিস্টেমে modular monolith দিয়ে শুরু; দল আর চাপ বাড়লে মাপা কারণে একটি একটি অংশ কেটে আলাদা (strangler fig).

নম্বর কোথায়: টেবিল (৪), হিসাব (২), boundary (২), distributed monolith (২)। পর্ব ৪৭

যেখানে নম্বর কাটে: “microservices সবসময় বেশি scalable”; network-এর দাম বাদ দেওয়া।

ধীর বনাম মৃত: মৃত সেবা ১ ms-এ “না” বলে; ধীর সেবা প্রতিটি thread কয়েক সেকেন্ড আটকে রাখে। Little-এর সূত্রে সেকেন্ডে ২০০টি call-এ W ১০০ ms থেকে ৫ সেকেন্ড হলে একসাথে চলা call ২০ থেকে ১,০০০ — ধরা যাক ২০০-র pool ফুরায়, সুস্থ কাজও থামে: cascading failure.

1. Timeout প্রতিটি call-এ, আর পুরো অনুরোধে একটি deadline, যা নিচের সব call-এ পৌঁছায়।
2. Retry শুধু ক্ষণিকের ত্রুটিতে আর idempotent কাজে; exponential backoff-এ অপেক্ষা = min(cap, base × ২^k), আর full jitter-এ তার ০ থেকে পুরো মানের মধ্যে এলোমেলো — একসাথে ব্যর্থ ক্লায়েন্টদের ঢেউ ভাঙে।
3. Circuit breaker: closed (সব যায়, ব্যর্থতা গোনে) → ব্যর্থতার হার সীমা ছাড়ালে open (কিছুই যায় না, সাথে সাথে fallback) → cooldown শেষে half-open (অল্প কয়েকটি পরীক্ষা) → সফলে closed, ব্যর্থে আবার open.
4. Bulkhead: প্রতিটি dependency-র আলাদা thread pool বা connection সীমা — জাহাজের খোপের মতো, একটিতে পানি ঢুকলেও বাকিরা ভাসে।

ছবি (খাতায়): তিনটি বৃত্ত closed, open, half-open; তীরে শর্ত — “ব্যর্থতা ≥ সীমা”, “cooldown শেষ”, “পরীক্ষা সফল”, “পরীক্ষা ব্যর্থ”।

হিসাব: ৩ × ৩ × ৩ = ২৭টি চেষ্টা একটি মূল অনুরোধে — retry নিজেই overload. প্রতিকার: শুধু একটি স্তরে retry, আর retry budget.

নম্বর কোথায়: ধীর বনাম মৃত (২), timeout ও retry (৩), state diagram (২), bulkhead (১), হিসাব (২)। পর্ব ৪৮ · পর্ব ১৮

যেখানে নম্বর কাটে: state diagram-এ half-open বাদ; “retry বাড়ালেই reliability বাড়ে”।

হিসাব: token bucket-এ যেকোনো T সেকেন্ডে সর্বোচ্চ b + r·T = ৫০ + ১০ × ১০ = ১৫০. Sliding counter-এ f = ১৫ ÷ ৬০ = ০.২৫, গণনা = ৮০ × ০.৭৫ + ৩০ = ৯০ < ১০০ — অনুরোধ যায়।

বহু gateway: ভাগ করা store-এ atomic INCR বা একটি script — “আগে পড়া, পরে লেখা”-র race-এ সীমা ফুটো হয়; বিকল্প প্রতিটি gateway-তে সীমার একটি ভাগ (অসম ভাগে ভুল)। উত্তরে 429 আর Retry-After; client-এ backoff ও jitter.

নম্বর কোথায়: টেবিল (৩), দুই হিসাব (২), বহু gateway (১)। পর্ব ৪৯ · পর্ব ১১

যেখানে নম্বর কাটে: rate limit আর load shedding এক বলা; burst-এর b বাদ দিয়ে ১০০ লেখা।

সংজ্ঞা: SLI = মাপা সংকেত (সফল অনুরোধের অনুপাত, p99 latency); SLO = লক্ষ্য (৩০ দিনে ৯৯.৯% সফল); SLA = চুক্তি, ভাঙলে ক্ষতিপূরণ — সাধারণত SLO-র চেয়ে ঢিলা।

Error budget: (১ − ০.৯৯৯) × ৪৩,২০০ মিনিট = ৪৩.২ মিনিট. অনুরোধে: ৫০০ × ২৫,৯২,০০০ সেকেন্ড × ০.০০১ = ১২,৯৬,০০০টি.

Burn rate: এখনকার error ratio ÷ (১ − SLO). ১৪.৪-এ এক ঘণ্টায় বাজেটের ১৪.৪ ÷ ৭২০ = ২% শেষ, আর এই গতিতে ৫০ ঘণ্টায় পুরো মাসের বাজেট — মানুষ জাগানোর মতো জরুরি। দুই জানালা (১ ঘণ্টা আর ৫ মিনিট) দুটিতেই সীমা ছাড়ালে alert — দ্রুত ধরা, আর সমস্যা মিটলে দ্রুত থামা।

নম্বর কোথায়: সংজ্ঞা (২), budget হিসাব (২), burn rate (১)। পর্ব ৫০

যেখানে নম্বর কাটে: SLA আর SLO এক বলা; CPU-র মতো কারণে alert, ব্যবহারকারীর লক্ষণে নয়।

সংজ্ঞা: RPO — সর্বোচ্চ কত সময়ের ডেটা হারানো চলে (অতীতের দিকে); RTO — সর্বোচ্চ কতক্ষণ বন্ধ থাকা চলে (ভবিষ্যতের দিকে)। Replication ভুল DELETE, corruption আর ransomware-ও কপি করে; backup অতীতের নির্দিষ্ট মুহূর্তে ফেরায়।

হিসাব: backup-এর ঠিক আগে বিপর্যয় হলে RPO = ৬ ঘণ্টা. কপি ফেরানো = ২ × ১০^১২ ÷ ২ × ১০^৮ = ১০,০০০ সেকেন্ড ≈ ২.৭৮ ঘণ্টা; যাচাই, log replay আর traffic সরানো যোগ হলে আসল RTO আরও বেশি — তা মাপা যায় শুধু restore-মহড়ায়।

নম্বর কোথায়: সংজ্ঞা (১), backup-এর কারণ (১), টেবিল (২), হিসাব (১)। পর্ব ৫১

যেখানে নম্বর কাটে: RPO আর RTO উল্টে বলা; কপি ফেরানোর সময়কেই RTO ধরা।

পার্থক্য: authentication — “আপনি কে” (না পারলে 401); authorization — “এটি পারেন কি না” (না পারলে 403). প্রতিটি সেবা প্রতিটি বস্তুতে মালিকানা যাচাই করে — এর অভাবই BOLA.

1. অ্যাপ একটি এলোমেলো code_verifier বানায়, তার SHA-256 hash হলো code_challenge.
2. ব্যবহারকারীকে authorization server-এ পাঠায়, challenge-সহ।
3. লগইন ও সম্মতির পর redirect-এ একটি অল্পমেয়াদি authorization code.
4. অ্যাপ code আর verifier দিয়ে token নেয় — access token (API-র জন্য), আর OIDC-তে ID token (client-এর জন্য)।
5. Server verifier-এর hash মিলিয়ে দেখে।

PKCE-এর কাজ: পথে চুরি যাওয়া code, verifier ছাড়া token-এ ভাঙানো যায় না। পুরোনো implicit flow নয়।

Envelope encryption: প্রতিটি ফাইল নিজের DEK দিয়ে encrypt; DEK-কে KMS-এর KEK দিয়ে মুড়ে ফাইলের পাশে রাখা; KEK কখনো KMS-এর বাইরে আসে না। Rotation-এ শুধু ছোট DEK আবার মোড়ানো; ফাঁস হলে ক্ষতি এক ফাইলে সীমিত।

নম্বর কোথায়: পার্থক্য (১), PKCE-র ধাপ (২), envelope (২)। পর্ব ৫২

যেখানে নম্বর কাটে: OAuth 2.0-কে পরিচয় যাচাইয়ের protocol বলা (পরিচয় দেয় OIDC); password encrypt করে রাখা — রাখতে হয় ধীর, salt দেওয়া hash-এ।

পরিধি: লম্বা URL → ছোট code; code → redirect; মেয়াদ; click analytics. NFR: redirect-এর p99 কম, উঁচু availability.

হিসাব: লেখা ১ কোটি ÷ ৮৬,৪০০ ≈ সেকেন্ডে ১১৬, peak ≈ ৩৪৭; পড়া ১০০ কোটি ÷ ৮৬,৪০০ ≈ ১১,৫৭৪, peak ≈ ৩৪,৭২২. চাপ পড়ায়। ৫ বছরে ১,৮২৫ কোটি link; পর্ব ৫৪-এর অনুমানে তিন কপিতে প্রায় ২৭ TB.

API: POST /v1/links → 201 আর code; GET /{code} → 302 আর Location.

ছবি (খাতায়): client → CDN/edge → LB → redirect service → cache → key-value store; লেখার পথে ID generator; redirect service থেকে ড্যাশ তীরে click event → stream → analytics.

Code: (ক) counter বা Snowflake + base62 — collision নেই, কিন্তু code অনুমান করা যায়। (খ) random বা hash-এর ৭ অক্ষর — ৬২^৭ ≈ ৩.৫২ লাখ কোটি সম্ভাব্য code, তবু birthday-র অঙ্কে ১ কোটি link-এ গড়ে n² ÷ (২M) ≈ ১৪টি collision — তাই লেখা শর্তসাপেক্ষ (না থাকলে তবেই), collision-এ নতুন code.

301 বনাম 302: 301 browser cache করে — পরের click আর সার্ভারে আসে না; analytics আর খারাপ link বন্ধের ক্ষমতা হারায়। তাই 302 বা 307.

Analytics আলাদা কেন: redirect-এর latency-তে লেখা যোগ না করা; event at-least-once, তাই event id দিয়ে dedup; unique visitor HyperLogLog-এ; analytics ভাঙলেও redirect চলে।

নম্বর কোথায়: পরিধি ও হিসাব (২), API (১), ছবি (২), code ও collision (২), 301/302 (১), analytics ও cache (২)। পর্ব ৫৪ · পর্ব ২৩ · পর্ব ৪৫

যেখানে নম্বর কাটে: “MD5-এর প্রথম ৭ অক্ষর” — collision-এর ব্যবস্থা ছাড়া; 301 লিখে analytics-ও দাবি; সংখ্যা ছাড়া “Kafka, Redis”.

হিসাব: ২০০ কোটি ÷ ৮৬,৪০০ ≈ সেকেন্ডে ২৩,১৪৮; peak × ৫ ≈ ১,১৫,৭৪১টি লেখা. ডিভাইসে পৌঁছানো কপি এর বহু গুণ (group আর একাধিক ডিভাইস) — পর্ব ৫৫-এর অনুমানে সেকেন্ডে ১৩ লাখের বেশি।

Sequence (খাতায় চারটি খাড়া রেখা: A-র ফোন, G1, chat service, G2 ও B):

1. A-র ফোন বার্তায় নিজের client id দেয় (retry নিরাপদ), WebSocket-এ gateway G1-এ পাঠায়।
2. Chat service কথোপকথনের পরের seq (যেমন ১০৪) দিয়ে conversation log-এ একবার লেখে; durable হলে A পায় ack — “sent”.
3. Registry দেখে B আছে G2-তে; pub/sub-এ G2-এর channel-এ publish.
4. G2 B-র socket-এ পাঠায়; B-র ফোন জানায় delivered_upto = ১০৪.
5. B অফলাইন হলে push notification; ফিরলে নিজের cursor (শেষ দেখা seq) থেকে sync.

ক্রম ও duplicate: ক্রম দেয় সার্ভারের প্রতি-কথোপকথন seq, ফোনের ঘড়ি নয়; ফাঁক দেখলে ফোন টেনে আনে। Delivery at-least-once; client id-তে সার্ভার dedup, seq দেখে ফোন duplicate ফেলে — প্রভাব একবার।

ব্যর্থতা ও trade-off: একটি gateway মরলে তার হাজারো client একসাথে ফেরে — backoff, full jitter আর প্রথম চেষ্টাও ছড়ানো; registry-র entry TTL-এ মোছে।

নম্বর কোথায়: হিসাব (১), sequence ও ছবি (৩), ক্রম ও duplicate (৩), অফলাইন (২), ব্যর্থতা (১)। পর্ব ৫৫ · পর্ব ১০ · পর্ব ৩৪

যেখানে নম্বর কাটে: ফোনের ঘড়ি দিয়ে ক্রম; “WebSocket দিলেই delivery নিশ্চিত”; অফলাইন ডিভাইস ভুলে যাওয়া।

হিসাব: ১ কোটি timeline লেখা; ১ কোটি ÷ ১ লাখ = ১০০ সেকেন্ড — এই সময়ে অন্যদের পোস্টও সারিতে আটকে থাকে।

Hybrid: follower-এর একটি সীমা (ধরা যাক ১০ হাজার) ছাড়ানো লেখকদের পোস্ট push হয় না; feed খোলার সময় তাঁদের সাম্প্রতিক পোস্ট টেনে এনে নিজের timeline-এর সাথে মেশানো হয়; বাকিদের push. সীমার দাম পড়ার সময়ে, তাই সীমা বাছতে হয় মেপে।

খুঁটিনাটি: timeline-এ শুধু ID, সীমিত দৈর্ঘ্য; লেখা, ছবি আর গণনা আলাদা করে (hydration); অনুপস্থিতদের timeline রাখা হয় না, ফিরলে আবার বানানো; নিজের পোস্ট সাথে সাথে নিজের feed-এ; মোছা আর block পড়ার মুহূর্তে ছাঁকা।

নম্বর কোথায়: টেবিল (৩), হিসাব (২), hybrid (৩), খুঁটিনাটি (২)। পর্ব ৫৬ · পর্ব ৩২

যেখানে নম্বর কাটে: পুরো পোস্ট timeline-এ কপি করা; “push দ্রুত” বলে লম্বা লেজের কথা না তোলা।

Double booking: সত্য এক জায়গায় — seat database-এ শর্তসহ লেখা: UPDATE seats SET status = 'held' … WHERE seat = ? AND status = 'available'; ০ সারি মানে আগেই নেওয়া। বা প্রতি-সিট version কলাম। Redis-lock বা app-এর memory নয় — lock রাখলেও তা শুধু অকারণ চেষ্টা কমায়, সঠিকতা দেয় না।

1. Waiting room (edge-এ): স্বাক্ষর-করা token-সহ সারি; ভর্তির হার database-এর সামর্থ্য থেকে — ২,০০০ ÷ ৪ = সেকেন্ডে ৫০০ জন, নিরাপত্তার জন্য আরও কিছু কম।
2. Hold: শর্তসহ UPDATE, মেয়াদসহ (ধরা যাক ১০ মিনিট)।
3. Payment: idempotency key-সহ; state machine-এ PENDING → SUCCEEDED বা FAILED, আর timeout-এ UNKNOWN — সরাসরি retry নয়, একই key-তে খোঁজ।
4. সফল হলে: hold → sold, টিকিট issue (outbox → notification).
5. মেয়াদ বা ব্যর্থতায়: hold ছেড়ে দেওয়া — compensation.
6. দিনশেষে: payment gateway-এর রিপোর্টের সাথে reconciliation.

Ledger: double-entry — প্রতিটি লেনদেনের লাইনগুলোর যোগফল শূন্য (যাত্রীর হিসাবে −৮০০, কোম্পানির প্রাপ্য হিসাবে +৮০০); entry শুধু যোগ হয়; ভুল শোধরায় উল্টো entry; টাকা পয়সায় পূর্ণসংখ্যা।

Trade-off: hold-এর মেয়াদ ছোট হলে টাকা দেওয়ার মাঝে সিট হারায়; বড় হলে না-কেনা মানুষের hold সিট আটকে রাখে।

নম্বর কোথায়: double booking (৩), প্রবাহ (৩), payment timeout (১), ledger (২), হিসাব (১)। পর্ব ৬০ · পর্ব ২৪ · পর্ব ২৫

যেখানে নম্বর কাটে: “Redis lock দেব”; “autoscaling করব” — database এভাবে বাড়ে না; balance কলাম সরাসরি বদলানো।

সহনশীলতা: লেখায় N − W = ১, পড়ায় N − R = ১; একটি বিকলে বাকি দুটিরই অপেক্ষা করতে হয়, তাই p99 বাড়ে (পর্ব ৬১-এর simulator-এ put-এর p99 ৪.৬ থেকে ৬১.৩ ms).

Vector clock: A-ঘরে প্রথমটি বড় (২ > ১), B-ঘরে দ্বিতীয়টি (১ > ০) — কোনোটি অন্যটির সব ঘরে ≥ নয়, তাই concurrent. Store দুটিই sibling হিসেবে রাখে, get দুটিই ফেরত দেয়, client মিলিয়ে নতুন context-সহ put করে (cart-এ union — মোছা জিনিস ফিরে আসতে পারে)। LWW হলে একটি নিঃশব্দে হারাত।

Sloppy quorum: preference list-এর বাইরের node-এর ack W-এ গোনা — লেখার availability কেনে (পর্ব ৬১-এ ৯৩.২৯% থেকে ১০০%), কিন্তু hint পৌঁছানো পর্যন্ত R + W > N-এর overlap হারায় — কিছু stale read. শর্তসাপেক্ষ লেখা বা অনন্যতা লাগলে প্রতি shard-এ Raft.

নম্বর কোথায়: অংশগুলো (৩), সহনশীলতা (১), vector clock ও sibling (৩), sloppy quorum (২), বিকল্প (১)। পর্ব ৬১ · পর্ব ৪১ · পর্ব ৪৬

যেখানে নম্বর কাটে: “একটি তৈরি NoSQL নিন” বলে অংশের নাম না দেওয়া; LWW-কে নিরাপদ default বলা।

High-level design পুরো সেবার উপাদান, তাদের সংযোগ, ডেটার পথ আর ব্যর্থতায় আচরণ ঠিক করে; low-level design একটি সার্ভিসের ভেতরের class, interface আর pattern. এই কোর্স প্রথমটি নিয়ে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… কোনটি আগে? — high-level; কোন সেবা কোন ডেটার মালিক না জেনে class বানানো অর্থহীন। পর্ব ০১

গড় ধীরতম অনুরোধগুলো লুকায়; p99 বলে ১০০টির ৯৯টি এর চেয়ে দ্রুত। আর fan-out-এ একটি ধীর উত্তরই পুরো অনুরোধ ধীর করে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… তিন সার্ভারের p99-এর গড় কি সেবার p99? — না; histogram-এর bucket যোগ করে তারপর percentile. পর্ব ০৪ · পর্ব ৫০

আট ধাপ: পরিধি ও requirement, হিসাব, API, data model, high-level design, deep dive, failure ও trade-off, wrap-up — দরকারে পেছনে ফিরে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… হিসাব কেন API-র আগে? — সংখ্যাই বলে চাপ কোথায় (পড়া না লেখা), তাই কোন অংশে গভীরে যাবেন। পর্ব ০৬

TCP ১ + TLS 1.3 ১ + অনুরোধ ১ = ৩ RTT (TLS 1.2-এ ৪, QUIC-এ ২); DNS আলাদা। RTT ১৫০ ms হলে শুধু এতেই প্রায় ৪৫০ ms.
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… কমাবেন কীভাবে? — keep-alive আর connection pool, HTTP/2-এর multiplexing, কাছের edge — আলোর গতি কোডে কমে না। পর্ব ০৭

Load balancer মূলত ভার ভাগ করে; API gateway L7-এ API-র নীতি প্রয়োগ করে — token যাচাই, quota, transformation, version routing. একই software দুটো কাজই পারে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… gateway নিজেই SPOF হলে? — কয়েকটি stateless instance, কয়েকটি zone, সামনে L4 LB বা anycast. পর্ব ১১

পাবলিক আর HTTP caching-নির্ভর API-তে REST; ভেতরের দ্রুত, টাইপ-করা call আর streaming-এ gRPC; বহু ক্লায়েন্টের ভিন্ন ভিন্ন ডেটা চাহিদায় GraphQL বা BFF.
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… GraphQL-এ N+1 কী? — প্রতিটি parent-এর জন্য child-এর আলাদা query; key জমিয়ে এক batch-এ আনা (DataLoader-ধাঁচ)। পর্ব ০৯

JavaScript-এর number একটি double; ২^৫৩-এর ওপরে সব পূর্ণসংখ্যা হুবহু রাখতে পারে না, তাই Snowflake-ধাঁচের ID নিঃশব্দে বদলে যায়।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… Protobuf-এ মুছে ফেলা field number আবার ব্যবহার করা যায় না কেন? — পুরোনো ডেটা আর পুরোনো কোড সেটিকে আগের অর্থে পড়বে; reserved দিয়ে আটকান। পর্ব ১২

Vertical মানে বড় যন্ত্র — সহজ, কিন্তু ছাদ, দামের বাঁক আর single point of failure; horizontal মানে বেশি যন্ত্র — লাগে load balancer, stateless নকশা আর সমন্বয়।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… ৫% কাজ serial হলে সর্বোচ্চ কত গুণ? — Amdahl-এ ১ ÷ ০.০৫ = ২০ গুণ, যত যন্ত্রই দিন। পর্ব ১৩

চাপ = R(১ − h); miss ০.১ থেকে ০.০১ — দশ গুণ কম। প্রতিটি বাড়তি “নয়” আবার দশ গুণ।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… তাহলে CDN বিকল হলে? — ৯৯% hit-এর সাইটে origin-এ হঠাৎ ১০০ গুণ চাপ; তাই origin shield, request collapsing আর origin-এর সামনে সীমা। পর্ব ১৭

HTTP/2-এর সংযোগ দীর্ঘজীবী আর multiplexed; L4 load balancer শুধু নতুন সংযোগ ভাগ করে, তাই পুরোনো সংযোগের সব call পুরোনো pod-এই যায়।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… সমাধান? — L7 proxy, client-side load balancing, বা সংযোগের সর্বোচ্চ বয়স বেঁধে দেওয়া। পর্ব ১৪ · পর্ব ০৯

না। ACID-এর C মানে অ্যাপের নিয়ম আর constraint রক্ষা (“balance শূন্যের নিচে নয়”); CAP-এর C মানে linearizability — সব কপি মিলে যেন একটিই কপি।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… ACID-এর I আর CAP-এর C-র সম্পর্ক? — I বহু object-এর transaction-এর ক্রম (serializability), CAP-এর C একটি object-এর বাস্তব সময়ের ক্রম; দুটি মিলে strict serializability. পর্ব ২৪ · পর্ব ৪০

Replication একই ডেটার কপি বাড়ায় — টিকে থাকা আর পড়া; partitioning ডেটা ভাগ করে — ক্ষমতা আর লেখা। বাস্তবে দুটো একসাথে চলে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… Replication কি লেখার ক্ষমতা বাড়ায়? — না; প্রতিটি লেখা প্রতিটি কপিতে যায়। পর্ব ২২ · পর্ব ২৩

Inverted index হলো শব্দ → ডকুমেন্টের সাজানো তালিকা; লেখার মাঝের শব্দেও দ্রুত খোঁজে আর ranking (BM25) করা যায়। B-tree পুরো মান বা তার শুরু দিয়ে খোঁজে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… LIKE '%x%' কেন সার্চ নয়? — প্রতিটি খোঁজে সব সারি পড়ে, শব্দ বোঝে না, আর কোনটি বেশি মানানসই জানে না। পর্ব ২৭

Write skew — দুটি transaction একই শর্ত পড়ে আলাদা সারি লেখে, যেমন দুজন on-call ডাক্তারই ছুটি নেন। Snapshot isolation শুধু একই সারিতে দুজনের লেখা দেখে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… ঠেকাবেন কীভাবে? — SERIALIZABLE (SSI), শর্তের সারিতে SELECT … FOR UPDATE, বা সংঘাতকে একটি সারিতে আনা। পর্ব ২৪

লেখা আগে cache-এ, পরে batch-এ database-এ; flush-এর আগে cache বিকল হলে সেই লেখা হারায় — ক্ষতির জানালা flush-এর ব্যবধান। View count বা like-এর মতো counter-এ চলে, টাকায় নয়।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… ক্ষতি কমাবেন কীভাবে? — ছোট flush ব্যবধান, cache-এ replica বা append-only log. পর্ব ২৮

Invalidation না থাকলে সব স্তরের TTL-এর যোগফল — প্রতিটি স্তর আগের স্তরের পুরোনো কপি আবার নিজের পুরো TTL ধরে রাখতে পারে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… কমাবেন কীভাবে? — L1-এ pub/sub দিয়ে invalidation আর ছোট TTL; TTL থাকে নিরাপত্তা-জাল হিসেবে। পর্ব ৩০

গ্রহণের পরে বার্তা অন্যদের থেকে লুকানোর সময় (visibility timeout). কাজের চেয়ে ছোট হলে কাজ চলাকালেই আরেকজন একই বার্তা পায় — duplicate, এমনকি সুস্থ বার্তাও DLQ-তে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… লম্বা কাজে? — heartbeat দিয়ে মেয়াদ বাড়ানো, আর কাজ idempotent. পর্ব ৩১ · পর্ব ৩৭

যে বার্তা বারবার ব্যর্থ হয়, সে poison message; সর্বোচ্চ receive count (যেমন ৩) পেরোলে তাকে DLQ-তে আলাদা করা হয়, যাতে বাকিরা আটকে না থাকে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… DLQ-তে গেলে তারপর? — alert, কারণ ঠিক করে আবার পাঠানো (redrive); alert না থাকলে DLQ একটি কবরস্থান। পর্ব ৩১

Log compaction-এ log প্রতিটি key-এর শুধু শেষ মান রাখে, offset বদলায় না; CDC বা একটি টেবিলের অবস্থা নতুন consumer-কে শুরু থেকে ফেরাতে কাজে লাগে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… acks=all কি একাই যথেষ্ট? — না; replication factor ৩ আর min.insync.replicas ≥ ২ সাথে লাগে, নইলে ISR ছোট হয়ে একটি কপিতেই “OK”. পর্ব ৩৩

Choreography-তে প্রতিটি সেবা event শুনে নিজের কাজ করে, কেন্দ্র নেই; orchestration-এ একজন orchestrator ধাপগুলো ডাকে। প্রবাহ লম্বা আর compensation জটিল হলে orchestration.
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… choreography-র বড় বিপদ? — পুরো অবস্থা কেউ জানে না; timeout আর debugging কঠিন। পর্ব ৩২ · পর্ব ২৫

পুরোপুরি asynchronous model-এ একটি process-ও crash করতে পারলে কোনো deterministic consensus algorithm সব ক্ষেত্রে শেষ হওয়ার নিশ্চয়তা দিতে পারে না (FLP — Fischer, Lynch ও Paterson, ১৯৮৫)।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… তাহলে Raft চলে কীভাবে? — safety সবসময় রাখে; liveness পায় partial synchrony আর randomized timeout-এ। পর্ব ৩৮ · পর্ব ৪২

Partition বা ভুল failover-এ দুটি node নিজেকে leader ভেবে দুজনই লেখা নেয় — ডেটা দুই দিকে চলে যায়।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… ঠেকাবেন কীভাবে? — majority quorum (সংখ্যালঘু পক্ষ থামে), আর fencing token বা epoch দিয়ে পুরোনো leader-এর লেখা প্রত্যাখ্যান। পর্ব ৩৮ · পর্ব ৪৩

Monotonic clock; wall clock NTP-র সংশোধনে বা leap second-এ পেছাতে বা লাফাতে পারে, তাতে সময়কাল ঋণাত্মকও দেখাতে পারে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… Spanner commit-wait কেন করে? — TrueTime-এর অনিশ্চয়তার সীমা পার হওয়া পর্যন্ত অপেক্ষা, যাতে timestamp-এর ক্রম বাস্তব সময়ের ক্রম মানে। পর্ব ৩৯

একই p আর একই hash-এর sketch-গুলোর register ঘর ধরে max, তারপর একবার গণনা; আলাদা অনুমান যোগ করা চলে না — একই মানুষ দুবার গোনা হয়। m = ১৬,৩৮৪-এ ভুল প্রায় ০.৮১%, memory প্রায় ১২ KB.
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… Count-min sketch কেন কখনো কম দেখায় না? — প্রতিটি ঘরে আসল গণনা আর collision, শুধু যোগ হয়; সর্বনিম্নও তাই আসলের সমান বা বেশি। পর্ব ৪৫

প্রতিটি replica-র ঘর শুধু বাড়ে; max সবচেয়ে নতুন মান দেয়, আর একই অবস্থা দুবার মেলালেও ফল একই (idempotent). যোগ করলে duplicate দুবার গোনা হয়। {A:3, B:1} আর {A:2, B:4} মিলে {A:3, B:4}, মোট ৭.
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… CRDT দিয়ে ব্যাংক ব্যালান্স রাখবেন? — শুধু CRDT নয়; “শূন্যের নিচে নয়” রক্ষায় coordination লাগে। পর্ব ৪৬

Database-এর সমস্যায় সব pod একসাথে restart হয় — তাতে কিছুই সারে না, বরং reconnect-এর ঢল আসে। Liveness শুধু process নিজে আটকে আছে কি না দেখবে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… তাহলে readiness? — readiness শুধু traffic নেওয়া বন্ধ করে, restart করে না; সেখানেও যাচাই অগভীর রাখা। পর্ব ৪৮ · পর্ব ৫৩

Deploy মানে কোড সার্ভারে পৌঁছানো, release মানে ব্যবহারকারীর জন্য feature খোলা; feature flag দুটিকে আলাদা করে আর এক ক্লিকে বন্ধের সুইচ দেয়।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… image tag-এর বদলে digest কেন? — tag সরানো যায়, digest বিষয়বস্তুর hash; সব যন্ত্রে আর rollback-এ ঠিক একই bytes. পর্ব ৫৩

প্রতিটি মান একটি নতুন time series — cardinality বিস্ফোরণ, memory আর খরচ লাফিয়ে বাড়ে; user_id log বা trace-এর attribute.
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… head আর tail sampling? — শুরুতেই এলোমেলো বাছাই (সস্তা, বিরল error হারায়) বনাম trace শেষে বাছাই (error রাখে, কিন্তু trace id ধরে collector-এ routing লাগে)। পর্ব ৫০

301 স্থায়ী — browser cache করে, পরের click আর সার্ভারে আসে না; analytics আর খারাপ link বন্ধের ক্ষমতা হারায়। তাই সাধারণত 302 বা 307.
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… ৭ অক্ষরের random code-এ collision কত? — ৬২^৭ ≈ ৩.৫২ লাখ কোটি, তবু ১ কোটি link-এ গড়ে প্রায় ১৪টি; তাই শর্তসাপেক্ষ লেখা। পর্ব ৫৪

কয়েক সেকেন্ডের ছোট segment CDN-এ cache হয়, দেখা দ্রুত শুরু হয়, আর player গতি দেখে মাঝপথে মান বদলাতে পারে (adaptive bitrate).
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… transcoding সমান্তরাল কীভাবে? — keyframe-এ টুকরো, প্রতিটি টুকরো প্রতিটি মানে আলাদা কাজ — একটি DAG, প্রতিটি কাজ idempotent. পর্ব ৫৯

আগে সংখ্যাগুলো দশ গুণ করে দেখুন কোন স্তর প্রথম ভাঙে — সাধারণত database-এর লেখা বা একটি hot key; তারপর শুধু সেই স্তরে বদল (sharding, cache, async) — সব একসাথে নয়।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… আর একশো গুণ? — একাধিক region, cell-ভিত্তিক ভাগ, আর কোন ডেটায় শক্ত consistency সত্যিই লাগে তা নতুন করে বাছাই। পর্ব ০৬ · পর্ব ০১