4.4.26 · Coding › Databases
Har database ko choose karna padta hai ki woh correctness ke baare mein kitna strict rahega versus kitna available aur scalable rahega.
ACID = "Main tumhe kabhi galat data nahi dikhaunga, chahe tumhe wait karwana pade ya refuse karna pade."
BASE = "Main hamesha fast answer dunga, chahe mera answer thoda purana ho, aur main use jald hi theek kar lunga."
WHY yeh exist karta hai: ek single machine sasti aur asaani se strict ho sakti hai. Lekin jab data bahut saari machines mein spread ho jata hai (distributed systems), toh sab ko perfectly in sync rakhna slow aur fragile hota hai. Isliye hum strictness ko speed ke liye trade karte hain.
Transactions ke liye guarantees ka ek set (operations ka ek group jo ek unit ki tarah treat hota hai):
Atomicity — saare operations succeed hote hain, ya koi bhi nahi (koi half-done transactions nahi).
Consistency — har transaction DB ko ek valid state se doosri valid state mein le jaata hai (saare rules/constraints hold karte hain).
Isolation — concurrent transactions ek doosre ko disturb nahi karte; result aisa hota hai jaise woh ek-ek karke chale hon.
Durability — commit ho jaane ke baad, data crashes se survive karta hai (yeh permanent storage mein likha jaata hai).
Intuition Har letter kyun zaroori lagta hai (Feynman)
A : Bank transfer mein debit + credit dono hote hain. Agar sirf debit hoti hai, toh paisa gayab ho jaata hai. WHAT hum chahte hain: dono ko ek indivisible cheez ki tarah treat karo.
C : Agar ek rule kehta hai "balance ≥ 0", toh koi bhi transaction negative balance nahi chhodne diya jaata. HOW: DB rule-breaking transactions ko reject/rollback karta hai.
I : Do log ek hi account se ek saath withdraw karte hain. Bina isolation ke dono $100 read kar sakte hain aur dono $100 withdraw kar sakte hain. Isolation unhe logically queue mein laga deta hai.
D : Tumne dekha "Payment successful", power chali gayi — tumhara paisa better still moved hona chahiye.
Worked example ACID transfer of $50 from A to B
BEGIN ;
UPDATE acct SET bal = bal - 50 WHERE id = 'A' ; -- step 1
UPDATE acct SET bal = bal + 50 WHERE id = 'B' ; -- step 2
COMMIT ;
Yeh step kyun? BEGIN/COMMIT dono updates ko wrap karta hai taaki Atomicity apply ho. Agar step 2 fail ho jaaye, toh step 1 rolled back ho jaata hai. Isolation in-between state (jahan total paisa galat hai) ko doosre readers se chhupa deta hai. Durability ka matlab hai ki COMMIT ke baad crash hone par bhi data safe hai.
Intuition BASE kyun exist karta hai
WHAT problem: thousands of machines worldwide par, har read par ACID-style strong consistency maangne ka matlab hai har request par saari machines ko coordinate karna → slow + fragile (ek slow node sabko block kar deta hai).
HOW BASE help karta hai: har replica ko jo bhi available hai usse immediately answer karne do, aur differences ko background mein reconcile karo. Tum bahut bada scale + high availability paate ho, cost sirf yeh hai ki momentarily purana data dikh sakta hai.
Worked example BASE "like count" on a post
Tumne ek post ko like kiya. Write ek replica par hit karta hai aur instantly return karta hai (Basically Available ). Kuch seconds ke liye doosre user ke replica mein abhi bhi purana count dikhega (soft state ). Thodi der mein saare replicas naye count tak sync ho jaate hain (eventual consistency ).
Yeh acceptable kyun hai? Like-count ka 2 seconds ke liye ek se off hona kisi ko nuksaan nahi pahunchata — lekin slowness ya downtime pahunchata. Yahan strictness is cost ke worth nahi hai.
Intuition Jab network toot jaata hai toh sab kuch nahi mil sakta
CAP : ek distributed system mein network partition ke dauran tum at most teen mein se do guarantee kar sakte ho:
C onsistency (sabko latest write dikhti hai)
A vailability (har request ko non-error response milta hai)
P artition tolerance (system nodes ke beech dropped messages ke bawajood kaam karta rehta hai)
Networks zaroor partition honge, isliye P mandatory hai . Asli choice hai C vs A :
ACID-leaning systems CP choose karte hain: galat data se bachne ke liye refuse/wait karte hain.
BASE-leaning systems AP choose karte hain: waise bhi answer dete hain, baad mein reconcile karte hain.
Aspect
ACID
BASE
Goal
Abhi correctness
Availability + scale
Consistency
Strong, immediate
Eventual
Availability
Block/refuse kar sakta hai
Hamesha respond karta hai
Typical DB
PostgreSQL, MySQL, Oracle
Cassandra, DynamoDB, Riak
Best for
Paisa, inventory, bookings
Feeds, likes, caches, analytics
CAP side
CP
AP
Common mistake Steel-manned misconceptions
"BASE ka matlab hai bilkul bhi consistency nahi."
Yeh kyun sahi lagta hai : "eventual" sunne mein "shayad kabhi nahi" jaisa lagta hai. Fix: BASE zaroor converge karta hai — bas immediate nahi hota. Agar koi nayi writes na hon, toh replicas agreement guarantee karte hain; tum sirf timing khoate ho, destination nahi.
"ACID = SQL, BASE = NoSQL, hamesha."
Kyun sahi lagta hai: most famous ACID DBs relational hain; most BASE wale NoSQL hain. Fix: Yeh guarantees ke baare mein hai, data model ke baare mein nahi. NoSQL stores jaise MongoDB ACID transactions offer karte hain; kuch SQL setups loosely consistent chalte hain. Label contract describe karta hai, technology family nahi.
"Tumhe poore app ke liye ek choose karna hi hai."
Kyun sahi lagta hai: ek database "ACID DB" ya "BASE DB" hota hai. Fix: Modern systems inhe mix karte hain — payments ke liye ACID, activity feed ke liye BASE. Guarantee ko data ke galat hone ki cost se match karo.
"CAP tumhe P drop karne deta hai."
Kyun sahi lagta hai: P baaki dono ki tarah optional lagta hai. Fix: Partitions networking ki ek reality hain, design choice nahi. Jab ek hota hai tum sirf C aur A ke beech choose kar sakte ho.
Recall Ek 12-saal ke bachche ko samjhao (hidden)
Socho ek notebook jise alag-alag shehar mein rehne wale dost share karte hain.
ACID woh bahut careful dost hai: koi bhi kuch likhne se pehle, woh sabko call karta hai, sabko ek hi waqt mein update karwata hai, aur math double-check karta hai. Kabhi kuch galat nahi hota — lekin agar phone line down ho, toh woh likhne se hi mana kar deta hai jab tak theek na ho jaaye.
BASE woh easy-going dost hai: woh apni notebook mein turant likh leta hai aur tumhara sawaal instantly answer karta hai. Notebooks thodi der ke liye alag-alag ho sakti hain, lekin jald hi sab baat karte hain aur ek jaise ho jaate hain . Tum kabhi wait nahi karte, lekin ek moment ke liye tumhara answer thoda purana ho sakta hai.
Careful dost ko paison ke liye use karo. Easy-going dost ko "likes" count karne ke liye use karo.
Mnemonic Letters yaad karo
ACID khatta aur strict hota hai → A ll-or-nothing, C onstraints hold, I solated, D urable. Socho: acid kabhi jhooth nahi bolta, lekin yeh tumhe sting (block) kar sakta hai.
BASE soft aur soothing hota hai → B asically A vailable, S oft state, E ventually consistent. Socho: base gentle aur hamesha available hota hai, lekin thoda fuzzy.
Acid + Base chemical opposites hain → strictness vs flexibility.
ACID ka matlab kya hai? Atomicity, Consistency, Isolation, Durability
BASE ka matlab kya hai? Basically Available, Soft state, Eventual consistency
Atomicity kya guarantee karta hai? Transaction ke saare operations succeed hote hain ya koi bhi nahi (koi partial application nahi)
Isolation kya guarantee karta hai? Concurrent transactions interfere nahi karte; result kisi serial order ke barabar hota hai
Durability kya guarantee karta hai? Committed data crashes se survive karta hai (permanent storage mein persist hota hai)
"Eventual consistency" kya promise karta hai? Koi nayi writes na hon toh, saare replicas eventually same value par converge kar lete hain
BASE kyun exist karta hai? Bahut saari machines mein immediate consistency relax karke high availability aur scale paane ke liye
CAP theorem: distributed systems mein kaunsi property non-negotiable hai? Partition tolerance (P) — networks fail hote hi hain, chahe kuch bhi ho
ACID systems usually kaunsi CAP pair choose karte hain? CP (consistency + partition tolerance, availability sacrifice karke)
BASE systems usually kaunsi CAP pair choose karte hain? AP (availability + partition tolerance, strong consistency sacrifice karke)
Ek ACID-appropriate use case do. Bank transfers / inventory / seat booking (galat data ki cost bahut zyada hai)
Ek BASE-appropriate use case do. Like counts, news feeds, caches, analytics (staleness sasti hai)
ACID vs BASE choose karne ka decision rule kya hai? ACID jab galat data ki cost >> downtime ki cost; BASE jab downtime cost dominate kare
True/false: BASE ka matlab hai kabhi bhi koi consistency nahi. False — yeh eventual hai, absent nahi; replicas time ke saath converge karte hain
CAP Theorem
ACID Transactions
Eventual Consistency
Distributed Systems
NoSQL Databases
Replication and Partitioning
Isolation Levels
Two-Phase Commit
Correctness vs Availability tradeoff
Isolation no interference
Durability survives crash
Basically Available always responds
Soft state changes over time
Eventual consistency replicas converge
High scale + availability