"Network কাটবেই। প্রশ্ন শুধু একটা: তখন আপনার system কী করবে?"
স্টেজ ০৬ শেষে আমাদের system অনেকগুলো service এ ভাগ হয়েছে। প্রতিটা service এর নিজের database, নিজের machine। এতে team গুলো স্বাধীন হয়েছে। কিন্তু একটা পুরোনো নিশ্চয়তা হারিয়ে গেছে: একটাই database এ একটা transaction দিয়ে সব কাজ একসাথে করা।
এই স্টেজে আমরা সেই হারানো নিশ্চয়তা আবার গড়বো, তবে distributed system এর নিয়ম মেনে। শুরু হবে CAP theorem দিয়ে, যেখানে দেখবো network কাটলে কী ছাড় দিতে হয়। তারপর consensus, saga, আর exactly-once। এই স্টেজটা একটু কঠিন, তাই ধীরে পড়ুন। প্রতিটা ধারণা একটা বাস্তব ঘটনা দিয়ে শুরু হবে।
০১ এই স্টেজে যা শিখবো
| সেশন | শিরোনাম | এই সেশনের লক্ষ্য |
|---|---|---|
| সেশন ১৫ | CAP Theorem (Deep Dive) | Network partition, CAP এর consistency আর availability, CP বনাম AP, CA কেন হয় না, PACELC, quorum (N, R, W) আর strong থেকে eventual পর্যন্ত consistency level। |
| সেশন ১৬ | Consensus (Raft, Paxos) | Majority quorum, Raft এর role আর term, randomized timeout দিয়ে leader election, log replication আর commit index, split brain ঠেকানো, ৩ বা ৫ node এর হিসাব, আর Paxos ও etcd/ZooKeeper/Consul/Kafka KRaft। |
| সেশন ১৭ | Distributed Transactions, Saga, 2PC | Service জুড়ে transaction কেন কঠিন, 2PC এর prepare/commit আর blocking problem, saga আর compensating transaction, choreography বনাম orchestrator, outbox pattern, আর user কে pending/confirmed/refunded অবস্থা দেখানো। |
| সেশন ১৮ | Idempotency, Exactly-once vs At-least-once | HTTP idempotency key আর stored response, একসাথে আসা duplicate, idempotency window আর dedup table এর আকার, natural idempotency, exactly-once delivery বনাম effectively-once processing, Kafka transaction, inbox pattern, আর end-to-end idempotency। |
০২ স্টেজ শেষে যা যা করতে পারবেন
- Network partition কী, আর তখন consistency ও availability এর মধ্যে কেন একটা বেছে নিতে হয়, সেটা বোঝাতে পারবেন।
- CP আর AP system চিনতে পারবেন, আর quorum (R + W > N) দিয়ে consistency হিসাব করতে পারবেন।
- Raft এ leader election আর log replication কীভাবে কাজ করে, সেটা ধাপে ধাপে বলতে পারবেন।
- 2PC এর blocking সমস্যা, আর saga ও compensating transaction দিয়ে তার বিকল্প ব্যাখ্যা করতে পারবেন।
- Outbox pattern দিয়ে database আর event একসাথে নির্ভরযোগ্যভাবে লেখা বোঝাতে পারবেন।
- Exactly-once delivery কেন অসম্ভব, কিন্তু effectively-once processing কীভাবে সম্ভব, সেটা বলতে পারবেন।
০৩ এর পর যা আসছে...
স্টেজ ০৭ শেষে আপনি জানেন, distributed system কেন কঠিন, আর কঠিন সমস্যাগুলো কীভাবে সামলাতে হয়। কিন্তু production এ system চালালে আরেকটা প্রশ্ন আসে: কিছু ভুল হলে আপনি টের পাবেন কীভাবে, আর user বোঝার আগেই ঠিক করবেন কীভাবে? স্টেজ ০৮ এ আসছে observability আর reliability: logging, metrics, tracing, alerting, circuit breaker আর chaos engineering।