Core Building Blocks — 12 Fundamental Concepts (Part 3)
I'm Rudraksh Laddha — a DevOps engineer and emerging full-stack developer, passionate about building scalable, reliable systems that solve real-world problems.
With a solid foundation in cloud infrastructure automation using tools like Kubernetes, Docker, Terraform, and AWS, I thrive in environments where efficiency, resilience, and automation are key.
But my journey doesn't stop at infrastructure. I'm actively expanding into full-stack development, building dynamic applications using React, Node.js, and MongoDB. Whether it's designing cloud-native CI/CD pipelines or developing intuitive user interfaces, I enjoy creating end-to-end solutions — from server to screen.
Right now, I'm: 🧩 Building full-stack applications that merge DevOps reliability with engaging frontend experiences 🛠️ Contributing to open-source projects, learning through collaboration and real-world scenarios 🚀 Growing Virendana Ui, my own UI library focused on expressive, clean design systems 🚀 Growing Learn Virendana, where I share my personalized learning journey — from beginner to experienced 🎮 Developing side projects like 2048 Rush, blending product thinking with scalable infrastructure My long-term goal? To bridge DevOps and development — building products that are not just functional and fast, but also resilient, beautiful, and ready for scale.
Each concept below follows the same structure: What it is → Why it exists → When to use → When NOT to use → Trade-offs → Real examples → Diagram → Beginner mistakes.
The 12 Concept are :
Requirements Clarification (Part 1)
Back-of-Envelope Estimation (Part 1)
Databases — SQL vs NoSQL (Part 2)
Caching (Part 2)
Load Balancing
API Design
Message Queues + Event-Driven Systems
Consistency vs Availability (CAP Theorem)
Scaling Strategies
Fault Tolerance + Reliability
.CDN (Content Delivery Network)
Data Partitioning (Sharding)
But in this article we cover only two concept
5. Load Balancing
What it is: Distributes incoming requests across multiple servers so no single server is overwhelmed.
WHY it exists: One server has finite CPU/memory. Load balancers let you add more servers and distribute work.
Algorithms:
| Algorithm | How it works | Best for |
|---|---|---|
| Round Robin | Request 1 → Server 1, Request 2 → Server 2... | Uniform workload |
| Least Connections | Route to server with fewest active connections | Variable request duration |
| IP Hash | Hash client IP to always route to same server | Sticky sessions |
| Weighted Round Robin | Powerful servers get more requests | Heterogeneous fleet |
Layer 4 vs Layer 7:
L4 (Transport): Routes by IP/TCP. Faster, dumber.
L7 (Application): Routes by URL, headers, cookies. Slower, smarter (can route /api to API servers, /static to CDN).
Health checks: Load balancers ping servers. If a server fails health check, traffic is rerouted. This is how you get zero-downtime deployments.
Beginner mistake: Assuming load balancer = solved scaling. LB is just traffic distribution. Your DB can still be the bottleneck.
6. API Design
What it is: The contract between your system and its clients (or between internal services).
WHY it exists: Systems need to communicate. APIs define HOW they communicate.
REST vs GraphQL vs gRPC:
| REST | GraphQL | gRPC | |
|---|---|---|---|
| Best for | Public APIs, CRUD | Flexible client queries | Internal microservices |
| Protocol | HTTP/JSON | HTTP/JSON | HTTP/2 + Protobuf |
| Performance | Medium | Medium | High |
| Flexibility | Low | High | Low |
Good API design rules:
Stateless: Each request contains all info needed (no server-side session state)
Versioned:
/api/v1/usersnot/api/users(allows evolution)Rate limited: Protect from abuse and runaway clients
Idempotent: POST creates, PUT updates (calling PUT twice has same result as once)
Beginner mistake: Designing APIs that return more data than needed. This wastes bandwidth and slows clients.
