System DesignMastery
--Core Components — মূল বিল্ডিং ব্লক

CAP Theorem & Consistency

Duration৩০-৪৫ মিনিট
LevelAdvanced
FocusArchitectural Theory
001Concept

CAP Theorem কেন শিখতে হবে?

আপনি একটা distributed system design করছো। Interview এ জিজ্ঞেস করলো — "আপনার system এ network failure হলে কী হবে? User কি wrong data দেখবেন নাকি error পাবেন?" — এই question এর answer হলো CAP Theorem।

Cassandra vs MongoDB vs PostgreSQL কোনটা choose করবেন — এই decision এর পেছনে CAP আছে। Senior engineer হতে হলে এই trade-off বুঝতেই হবে।

DEFINITION

CAP Theorem বলে: একটা distributed system এ সর্বোচ্চ দুটো guarantee দেওয়া সম্ভব — Consistency, Availability, Partition Tolerance এর মধ্যে। তিনটা একসাথে impossible। Eric Brewer 2000 সালে propose করেন, 2002 সালে formally prove হয়।

002C, A, P Deep Dive

C, A, P — তিনটা কি মানে?

CCONSISTENCYAAVAILABILITYPPARTITION TOL.CPHBase, ZookeeperCASingle-node RDBMSAPCassandra, DynamoDB

C — Consistency

সব nodes এ same time এ same data। Write করার পর যেকোনো node থেকে read করলেন latest value পানয়া যাবেন। "All nodes see the same data simultaneously।"

A — Availability

প্রতিটি request এর response আসবেনই — error নয়, timeout নয়। কিছু nodes down থাকলেও system respond করবেন। তবে response টা stale হতে পারে।

P — Partition Tolerance

Network partition (nodes এর communication বিচ্ছিন্ন) হলেও system কাজ করতে থাকে। Distributed system এ P সবসময় দরকার — network কখনো ১০০% reliable না।

💡 Real Choice

Distributed system এ P বাদ দেওয়া যায় না। তাই real choice হলো: CP নাকি AP? Network partition হলে কোনটা sacrifice করবো — Consistency নাকি Availability?

🎯 Interview এ এটা বলুন

"CAP এ P সবসময় থাকবেন কারণ network failure real world এ inevitable। তাই practical choice হলো CP বা AP। Financial systems এ CP — wrong data catastrophic। Social media তে AP — stale data কয়েক seconds acceptable।"

003Network Partition

Network Partition হলে কি হয়?

NORMAL STATENode Abal=1000syncNode Bbal=1000AFTER PARTITION + WRITENode Abal=500 ✍✂✂✂no networkNode Bbal=1000 ← stale!CP CHOICENode B reads → Error দেয়"Service unavailable"AP CHOICENode B reads → 1000 দেয়(stale but available!)
Use CaseCP নাকি AP?কারণ
Bank balanceCPWrong balance দেখালে double-spending হবে
Facebook likesAPকয়েক seconds stale count দেখানো acceptable
Online bookingCPDouble-booking prevent করতে হবে
DNS recordsAPAlways available, propagation delay acceptable
Shopping cartAPCart lock হলে sale হারাবে, stale cart acceptable
Leader electionCPSplit-brain হলে catastrophic

CP Systems — Consistency Priority

Partition হলে কিছু requests reject করে। Wrong data দেবে না। Banking, coordination (Zookeeper), configuration management এর জন্য।

AP Systems — Availability Priority

Partition হলেও respond করে, কিন্তু stale data দিতে পারে। Eventually consistent। Social feeds, caching, DNS, shopping cart এর জন্য।

004Consistency Levels

Consistency — Strong থেকে Eventual

Levelমানে কিReal Example
StrongWrite এর পর সব nodes এ latest value। SlowestBank balance, Stock inventory
LinearizableReal-time order maintain। Operations globally orderedZookeeper, etcd
CausalCausally related operations ordered। Reply এর আগে post দেখা যাবেনChat apps, Comments
Read-your-writesআপনি নিজের write সবসময় দেখবেন। অন্যরা হয়তো দেখবেন নাInstagram — নিজের post দেখা
EventualEventually সব nodes same data। কখন হবে guarantee নেইDNS, YouTube view count, Likes

💡 Eventual Consistency Example

DNS update করলেন সারা বিশ্বে propagate হতে ২৪-৪৮ ঘণ্টা লাগতে পারে। এই সময় কেউ old IP দেখছে, কেউ new IP। এটাই Eventual Consistency।

tunable-consistency.cql
-- Cassandra তে per-query consistency level configure করা যায়!
-- এটাই practical CAP flexibility

-- QUORUM: majority nodes (N/2+1) agree করলেন success
-- 3 nodes থাকলে QUORUM = 2 nodes agree করতে হবে
INSERT INTO accounts (id, balance)
VALUES (uuid(), 10000)
USING CONSISTENCY QUORUM;   -- Strong-ish, balanced

-- ONE: শুধু একটা node respond করলেনই success (fastest)
SELECT * FROM user_activity WHERE user_id = 101
CONSISTENCY ONE;            -- Fast, eventually consistent

-- ALL: সব nodes confirm করতে হবে (strongest, slowest)
UPDATE accounts SET balance = balance - 5000
WHERE account_id = 101
CONSISTENCY ALL;            -- Critical financial op
005PACELC Theorem

PACELC — CAP এর Extension

CAP শুধু partition সময়ের কথা বলে। কিন্তু normal operation এও trade-off আছে। Daniel Abadi 2012 সালে PACELC propose করেন।

📌 PACELC মানে

Partition থাকলে Availability vs Consistency; Else (normal এ) Latency vs Consistency। যত বেশি nodes এ replicate করবেন, তত বেশি consistent কিন্তু তত বেশি latency।

DatabasePartition TimeNormal Operationসহজ কথায়
DynamoDBPA (available)EL (low latency)Fast, eventual consistency
CassandraPA (available)EL (configurable)Tunable, default fast
MongoDBPC (consistent)EC (some latency)Strong consistency
PostgreSQLPC (consistent)EC (ACID overhead)Full ACID, slower
006Real World Examples

বড় কোম্পানিগুলো কীভাবে করেছেনে

📦 Amazon DynamoDB — AP by Design

Amazonconsciously AP choose করেছেনে। "Always available" guarantee। Werner Vogels (Amazon CTO): "Network partition হলে আপনাকে পুরোনো cart দেখাবো কিন্তু cart lock করবো না।" Availability থেকে Consistency বেশি important — cart lock হলে sale হারাবে। তবে checkout এ CP enforce হয়।

🔒 Apache Zookeeper — CP by Design

Distributed coordination service — CP choice। Leader election, distributed locks, config management। Wrong value এখানে catastrophic — দুটো nodes যদি একসাথে leader মনে করে, split-brain problem হয়। Partition এ কিছু clients reject হলেও correct data দেওয়া জরুরি। Kafka broker coordination, HDFS এ Zookeeper use হয়।

💡 Split-brain কি?

Network partition এ দুটো partition নিজেকেই primary মনে করে — conflicting states তৈরি হয়। Solution: Quorum (majority voting) — ছোট partition writes accept করে না। Zookeeper, etcd এভাবে handle করে।

eventual-consistency-sim.py
import asyncio, time, random

class Node:
    def __init__(self, node_id):
        self.node_id = node_id
        self.data = {}       # Local state
        self.peers = []

    async def write(self, key, value):
        # AP: Local write, async sync — fire and forget
        self.data[key] = {'value': value, 'ts': time.time()}
        print(f"[{self.node_id}] Wrote {key}={value} (local)")
        asyncio.create_task(self._propagate(key))  # Async!

    async def read(self, key):
        # May return stale data!
        entry = self.data.get(key)
        val = entry['value'] if entry else None
        print(f"[{self.node_id}] Read {key}={val}")
        return val

    async def _propagate(self, key):
        # Simulate network delay (0.5-3 seconds)
        await asyncio.sleep(random.uniform(0.5, 3.0))
        for peer in self.peers:
            await peer._sync(key, self.data[key])

    async def _sync(self, key, entry):
        # Last-Write-Wins conflict resolution
        existing = self.data.get(key)
        if not existing or existing['ts'] < entry['ts']:
            self.data[key] = entry
            print(f"[{self.node_id}] Synced {key}={entry['value']}")

async def demo():
    a, b = Node("A"), Node("B")
    a.peers = [b]; b.peers = [a]

    await a.write("likes", 100)
    await b.read("likes")    # None! Not synced yet
    await asyncio.sleep(4)  # Wait for propagation
    await b.read("likes")    # 100 — eventually consistent!

asyncio.run(demo())
007Tools Classification

Database CAP Classification

DatabaseCAP TypeConsistencyAvailabilityBest For
ZookeeperCPStrongPartition = rejectLeader election, locks
HBaseCPStrongPartition = rejectBig data analytics
MongoDBCPStrong (default)Primary must respondContent, catalogs
CassandraAP (tunable)Tunable ONE→ALLAlways respondsSocial, IoT, logging
DynamoDBAP (default)Eventually/Strong99.999% SLAE-commerce, gaming
CouchDBAPEventualAlways availableOffline-first apps
PostgreSQLCPStrong (ACID)Single-node limitFinance, e-commerce
008Lesson Summary

SUMMARY — আজকে যা শিখলাম

Conceptএক লাইনে
CAP TheoremC + A + P একসাথে impossible। P সবসময় থাকে, তাই CP বা AP choose করুন
CP SystemsConsistency priority — Banking, Zookeeper
AP SystemsAvailability priority — Social, DNS, Cache
Eventual ConsistencyEventually সব nodes same, latency কম
PACELCNormal operation এ Latency vs Consistency trade-off
QUORUMMajority (N/2+1) nodes agreement
Split-brainPartition এ দুটো leaders — Quorum দিয়ে prevent করুন
009Knowledge Check
010Assignments
011Practical Lab
🎉

Phase 1 — Foundations Complete!

আপনি System Design Mastery Course এর Phase 1 সম্পূর্ণ করেছেনো। চারটি fundamental topic এ solid foundation তৈরি হয়েছে।

Topic 1: Scalability
Topic 2: Networking
Topic 3: Databases
Topic 4: CAP Theorem

PHASE 2 — Next Topics:

Caching Strategies · Message Queues · API Design · Microservices · Rate Limiting · System Design Case Studies