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

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

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

🧩 Modular monolith vs microservices — lesson 09

⏮️ दोन्हीपैकी काहीही येण्याआधी

One big ball of code where every change touched everything, or dozens of tiny services nobody could run locally.

✅ फायदे

  • modular monolith: one deploy, in-process calls, easy transactions, clear module borders
  • microservices: teams deploy alone, scale parts separately, fail separately

❌ तोटे

  • monolith: one deploy for all teams; one bad module can take it down
  • microservices: network hops cost latency and availability, distributed data, platform work

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

  • start modular; split a module out when a team or a scaling need clearly asks
  • microservices for many teams with separate release cycles

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

  • microservices for a team of four
  • a 'distributed monolith' — services that must all deploy together

🗄️ Relational vs key-value stores — lesson 04

⏮️ Before choosing

Every new app picked the fashionable database, then fought it for years.

✅ फायदे

  • relational: joins, transactions, flexible questions later
  • key-value / wide-column: predictable speed at huge scale for known lookups

❌ तोटे

  • relational: scaling writes past one primary needs work
  • key-value: you must know your access patterns up front; joins are your job

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

  • default to relational; add a store when an access pattern needs it
  • key-value for huge, simple lookups (sessions, carts, feeds)

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

  • a key-value store for a reporting-heavy app
  • five databases in a design with one team

🔁 Strong vs eventual consistency — lesson 10

⏮️ Replicas आधी

One copy — always correct, and down whenever that copy was down.

✅ फायदे

  • strong: every read sees the latest write — simple to reason about
  • eventual: faster, stays up during a split, cheaper across regions

❌ तोटे

  • strong: slower writes (quorums), may refuse during a split
  • eventual: stale reads, conflicts to resolve

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

  • strong for money, grades, inventory
  • eventual for counts, likes, feeds, caches

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

  • eventual for a bank balance
  • strong for a view counter

🤝 Two-phase commit vs saga — lesson 11

⏮️ Before distributed transactions

One database held everything, so one transaction was enough.

✅ फायदे

  • 2PC: all or nothing, looks like one transaction
  • saga: no global locks, each service stays independent, survives partial failure

❌ तोटे

  • 2PC: blocks if the coordinator dies; locks held across services
  • saga: in-between states are visible; every step needs an undo

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

  • 2PC inside one database cluster or a few tightly coupled resources
  • sagas across microservices (bookings, orders, payments)

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

  • 2PC across services owned by different teams
  • sagas whose compensations are not idempotent

📣 Fan-out on write vs on read — lessons 08, 17

⏮️ Before feeds

Every page load ran a big query across everyone you follow.

✅ फायदे

  • push (on write): reading is one lookup — fast feeds
  • pull (on read): posting is one write — cheap for huge audiences

❌ तोटे

  • push: a celebrity post means millions of writes
  • pull: every read gathers from many sources

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

  • push for normal authors, pull for celebrities (hybrid)
  • pull when reads are rare

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

  • pushing a 2M-follower post to every inbox
  • pulling for a feed read thousands of times a second

📬 Doing it now vs queueing it — lesson 07

⏮️ Before queues

The request sent 5M SMS itself and timed out.

✅ फायदे

  • queue: fast answers, workers scale separately, retries and a DLQ
  • synchronous: simple, the result is known at once

❌ तोटे

  • queue: at-least-once — consumers must be idempotent; results arrive later
  • synchronous: slow work makes every request slow

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

  • queue anything slower than a page load or that can wait
  • synchronous for what the user must see now

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

  • a queue for a read the user waits on
  • sending bulk messages inside the request

📌 Caching vs going to the database every time — lesson 05

⏮️ Before caches

Every read hit the database; the database became the bottleneck.

✅ फायदे

  • a small cache catches most of the popular reads
  • cuts latency and database cost

❌ तोटे

  • stale data until TTL or invalidation
  • one more system to run and size

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

  • read-heavy, popular data with tolerable staleness
  • expensive computations reused often

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

  • caching without a TTL or an invalidation plan
  • caching per-user data under a shared key