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

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

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

🎪 Scale up vs scale out — lesson 01

⏮️ Before the cloud

You bought the biggest server you could afford and hoped results day would fit.

✅ फायदे

  • up: no code changes, one machine to run
  • out: no ceiling, a lost server is just one of many

❌ तोटे

  • up: there is always a biggest size, and a restart takes everything down
  • out: the app must be stateless and the data layer must keep up

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

  • up: databases and small apps first
  • out: web and API tiers behind a load balancer

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

  • scaling out an app that keeps sessions in memory
  • scaling up forever instead of fixing a slow query

🌍 CloudFront caching vs serving everything from the origin — lessons 03, 04

⏮️ Before CDNs

Every parent, from every city, fetched every image and script from one server.

✅ फायदे

  • edge copies are close to the user — faster and cheaper
  • the origin sees only misses: a 99% hit ratio means 1% of the load

❌ तोटे

  • stale content until the TTL passes or you invalidate
  • personalised pages need care — never cache private data publicly

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

  • static UI (versioned files, long max-age); busy public pages (seconds of s-maxage)
  • origin shield when many edges miss at once

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

  • caching responses that set cookies or carry user data
  • invalidating /* on every deploy instead of versioned names

⚙️ EC2 Auto Scaling vs Kubernetes vs Lambda — lessons 06, 07, 08

⏮️ Before elastic compute

Capacity was a purchase order; a spike meant slow pages until next quarter.

✅ फायदे

  • Auto Scaling groups: simple, any software, per-instance control
  • Kubernetes: many services share nodes, HPA + Karpenter scale in seconds
  • Lambda: no servers, scales per request, pay per millisecond

❌ तोटे

  • instances take minutes to warm up
  • Kubernetes is a platform to run and learn
  • Lambda: cold starts, 15-minute limit, concurrency quotas, connection storms

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

  • steady services with known software: ASG
  • many containerised services: Kubernetes
  • spiky, event-driven, short work: Lambda

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

  • Lambda for a constant heavy workload that would be cheaper on reserved servers
  • Kubernetes for one small app

⚖️ Sticky sessions vs stateless servers — lesson 05

⏮️ Before shared session stores

The load balancer pinned each user to one server; when it died, everyone on it was logged out.

✅ फायदे

  • stateless: any server can answer, scale in and out freely
  • sticky: quick fix for legacy apps

❌ तोटे

  • stateless needs a shared store (Redis, DynamoDB) or signed tokens
  • sticky: uneven load, lost sessions on scale-in

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

  • new apps: stateless from day one
  • legacy apps: sticky as a bridge while moving state out

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

  • files uploaded to one server's disk
  • in-memory caches that disagree between servers

📌 Cache-aside vs write-through — lesson 09

⏮️ Before a cache

Every page view ran the same query on the database.

✅ फायदे

  • cache-aside: only what is read gets cached; the cache can fail and the app still works
  • write-through: the cache is always fresh

❌ तोटे

  • cache-aside: a miss costs a DB read; stale until TTL or delete
  • write-through: every write pays twice, cold data fills the cache

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

  • read-heavy data with tolerable staleness: cache-aside + TTL
  • small hot data that must be fresh: write-through

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

  • no TTL at all
  • caching per-user data under a shared key

📚 Read replicas vs partitioning (sharding) — lessons 10, 11

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

One database did every read and every write until it could not.

✅ फायदे

  • replicas: more reads with no schema change
  • partitioning: more writes AND more storage — scales without a ceiling

❌ तोटे

  • replicas lag; writes still go to one primary
  • partitioning: cross-partition queries and a key you must choose well

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

  • read-heavy apps: replicas + a proxy
  • write-heavy or huge data: partitions (DynamoDB, Citus, Vitess)

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

  • reading your own write from a lagging replica
  • a partition key where one value gets most of the traffic

📬 Doing work now vs through a queue — lesson 12

⏮️ Before queues

The request waited while the server built a PDF; a burst made every request slow.

✅ फायदे

  • the queue absorbs bursts; workers scale on backlog
  • failed work is retried, and poison messages are parked in a DLQ for a person to look at

❌ तोटे

  • the answer arrives later — the UI must say so
  • at-least-once delivery: work must be safe to repeat

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

  • emails, PDFs, image resizing, anything slower than a page load
  • smoothing spikes in front of a fragile system

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

  • queues for work the user must see immediately
  • workers that are not idempotent

🛟 Retrying vs failing fast — lesson 13

⏮️ Before timeouts and breakers

One slow dependency held every thread; retries from every client hit it again at the same instant.

✅ फायदे

  • retries with exponential backoff + jitter recover from short blips
  • a circuit breaker fails fast and gives the sick service room to recover

❌ तोटे

  • retries multiply load — without jitter they arrive together
  • a breaker that opens too easily turns a blip into an outage

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

  • retry idempotent calls a few times, with jitter and a total time budget
  • breakers around every remote dependency; a fallback (cached page) behind each

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

  • retries on non-idempotent payments without an idempotency key
  • no timeout at all — the default in many HTTP clients