#SystemDesign

Nitin.nn @NitinthisSide_

🧵 Day 21/30 — #SystemDesign Load Balancer: The silent system that keeps everything fast & alive One server handling all traffic? Works… until it doesn’t. Traffic spikes → server overload → downtime. That’s why systems use a Load Balancer. A load balancer sits between users and servers and distributes incoming requests across multiple instances. Flow: User → Load Balancer → Multiple Servers Goal: → No single server overloaded → Better performance → High availability Types (keep it simple) Layer 4 (Transport) → Works on IP + Port → Fast, less intelligent Layer 7 (Application) → Works on HTTP/HTTPS → Smart routing (headers, paths) Common Algorithms → Round Robin (equal distribution) → Least Connections (send to least busy) → IP Hash (same user → same server) → Weighted (based on server capacity) Why It Matters → Handles traffic spikes → Improves uptime → Enables horizontal scaling → Supports failover → Better latency Real Usage → AWS ELB / ALB → NGINX → HAProxy → Cloudflare Every scalable system uses one. Golden Rule Scaling = adding more servers. Load balancer = using them efficiently. #30DaysOfSystemDesign #LoadBalancing #BackendEngineering

Nitin.nn @NitinthisSide_

🧵 Day 22/30 — #SystemDesign Database Indexing: Why some queries take milliseconds… and others take forever Your database works fine with 1K users. At 1M users, the same query suddenly becomes slow. Nothing changed in code. The problem is how data is searched. That’s where Indexing comes in. An index is like a shortcut that helps the database find data quickly without scanning every row. ⸻ Without index: → DB scans entire table (Full Table Scan) → Time complexity grows with data → Slow queries at scale With index: → DB jumps directly to required data → Faster reads → Efficient lookups ⸻ Simple Example User table with 10M rows. Query: SELECT * FROM users WHERE email = ‘abc@gmail.com’ Without index: → Check all 10M rows With index on email: → Direct lookup in milliseconds ⸻ Why It Matters → Faster search queries → Better performance at scale → Reduced database load → Improved user experience ⸻ Tradeoff Indexes are not free: → Extra storage → Slower writes (index update needed) → Too many indexes hurt performance ⸻ Golden Rule Index what you query often. Not everything. #30DaysOfSystemDesign #DatabaseIndexing #BackendEngineering

Nitin.nn @NitinthisSide_

🧵 Day 10/30 — #SystemDesign Microservices vs Monolith: How should you structure your backend? Many projects start with one codebase, one database, and one deployment. It feels simple, fast, and productive. But as products grow, teams expand, traffic increases, and features multiply, architecture decisions begin to matter. That’s where the debate starts: Monolith or Microservices? A Monolith means your application is built as one unified system. User auth, payments, notifications, admin panel, APIs — all live inside one codebase and are deployed together. This works extremely well for many startups because it keeps development simple. Benefits of Monolith: → Faster to build initially → Easier local development → Simpler deployment pipeline → Easier debugging in one place → Lower operational overhead → Great for small teams That’s why many successful companies started as monoliths.

Nitin.nn @NitinthisSide_

🧵 Day 13/30 — #SystemDesign Database Replication: How systems stay fast and available even when one DB fails Many apps run smoothly with one database… until traffic grows or the database crashes. Suddenly reads become slow, maintenance becomes risky, and one machine becomes a single point of failure. That’s why production systems use Database Replication. Replication means copying data from one database server (Primary) to one or more secondary servers (Replicas). The primary usually handles writes, while replicas help with reads and failover. Flow: App Writes → Primary DB Primary Syncs Data → Replicas Read Requests → Replicas This improves performance and reliability. ----------------- Why Replication Matters Without replication: → One DB handles everything → Read traffic overloads server → Downtime risk if DB fails → Hard maintenance windows → Backups affect performance With replication: → Scale read traffic → Better availability → Disaster recovery options → Safer maintenance → Lower load on primary It is one of the first steps in database scaling. ------------------- Primary vs Replica Primary Database → Accepts INSERT / UPDATE / DELETE → Source of truth → Sends changes to replicas Replica Database → Copies primary data → Usually serves read queries → Can be promoted during failure Many systems use 1 primary + multiple replicas. ------------------- Real Example E-commerce platform: → Order placement writes to Primary → Product browsing reads from Replicas → Search suggestions may read from Replicas → Reports can run on Replicas This keeps critical writes fast while distributing reads. ------------------- Replication Types 1. Synchronous Replication Primary waits until replica confirms write. Pros: → Strong consistency Cons: → Slower writes 2. Asynchronous Replication Primary confirms write immediately, replica updates later. Pros: → Faster writes Cons: → Small lag possible Most large systems balance speed vs consistency carefully. --------------------- Challenges Most Ignore Replication helps a lot, but adds tradeoffs: → Replica lag (stale reads) → Failover complexity → Split brain risks → Write bottleneck still on primary → Monitoring needed → Backups still important Replication improves systems, but doesn’t remove architecture thinking.