← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. प्रत्येक मोठ्या कल्पनेसाठी: आधी जीवन कसे होते, प्रामाणिक फायदे ✅ / तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

📚 Synchronous vs asynchronous replication — lesson 05

⏮️ Replicas आधी

One server; when it died, everything waited for a restore from last night's backup.

✅ फायदे

  • sync: an acknowledged write survives a failover
  • async: fast writes, followers far away are fine

❌ तोटे

  • sync: every write waits for a follower; a slow follower slows everyone
  • async: acknowledged writes can be lost on failover

👍 वापरा जेव्हा

  • sync (or semi-sync) for money and grades
  • async for read replicas, analytics, far regions

👎 दोनदा विचार करा जेव्हा

  • async with automatic failover for data you cannot lose
  • sync to a follower on another continent

✂️ CP vs AP during a partition — lesson 08

⏮️ Before networks split

One machine never disagreed with itself.

✅ फायदे

  • CP: never a wrong answer
  • AP: always an answer

❌ तोटे

  • CP: some users get errors while the road is cut
  • AP: stale reads and conflicts to settle later

👍 वापरा जेव्हा

  • CP for balances, bookings, locks, leader election
  • AP for carts, likes, presence, caches

👎 दोनदा विचार करा जेव्हा

  • AP for a seat booking
  • CP for a like counter

🕰️ Last-writer-wins vs keeping both — lessons 02, 08

⏮️ Before thinking about it

Whatever arrived last overwrote the rest.

✅ फायदे

  • LWW: simple, always one value
  • merge / CRDTs / asking a person: nothing is silently lost

❌ तोटे

  • LWW: clock skew decides; real writes vanish
  • merge: more work, sometimes a human must choose

👍 वापरा जेव्हा

  • LWW for caches and 'latest wins' data like presence
  • merge for documents, carts, anything a person typed

👎 दोनदा विचार करा जेव्हा

  • LWW with wall clocks across machines for important data
  • merging where a single truth is required (money)

👑 Consensus (Raft) vs one leader database — lesson 09

⏮️ Before consensus systems

A hand-picked primary; when it failed, a person promoted another — sometimes two at once.

✅ फायदे

  • consensus: automatic, safe leader election; never two leaders in a term
  • one primary: simple, fast, well understood

❌ तोटे

  • consensus: needs a majority up; writes cost a round trip to a majority
  • one primary: failover is the hard part

👍 वापरा जेव्हा

  • consensus for coordination data: leaders, config, locks (etcd, ZooKeeper)
  • a managed database's own failover for app data

👎 दोनदा विचार करा जेव्हा

  • building your own consensus
  • putting bulk app data into etcd

🔏 A lease alone vs a lease + fencing token — lesson 10

⏮️ Before leases

Locks that never expired — a crashed holder blocked everyone forever.

✅ फायदे

  • lease: a crashed holder cannot block forever
  • fencing token: a paused holder cannot overwrite newer work

❌ तोटे

  • lease alone: a paused holder writes after expiry
  • fencing: the storage must check tokens

👍 वापरा जेव्हा

  • always pair leases with fencing tokens the storage enforces
  • prefer designs that need no lock at all (idempotent upserts)

👎 दोनदा विचार करा जेव्हा

  • trusting a lease across long GC pauses
  • locks with no expiry

🚧 Unbounded vs bounded queues — lesson 12

⏮️ Before backpressure

Every request was accepted; under overload the line grew until everything timed out.

✅ फायदे

  • bounded: latency stays sane; overload becomes a clear 'try later'
  • unbounded: nothing is refused at the door

❌ तोटे

  • bounded: some requests are shed
  • unbounded: every request gets slower, memory grows, then everything fails

👍 वापरा जेव्हा

  • bounded queues with 429/503 + Retry-After and client backoff
  • shed low-priority work first

👎 दोनदा विचार करा जेव्हा

  • unbounded in-memory queues in a service
  • retries without backoff into an overloaded system