Core Building Blocks — 12 Fundamental Concepts (Part 5)
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.
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.
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 (Part 3)
API Design (Part 3)
Message Queues + Event-Driven Systems (Part 4)
Consistency vs Availability (CAP Theorem) (Part 4)
Scaling Strategies
Fault Tolerance + Reliability
.CDN (Content Delivery Network)
Data Partitioning (Sharding)
But in this article we cover only two concept
9. Scaling Strategies
What it is: How you add capacity to your system as demand grows.
Vertical Scaling (Scale Up):
Add more CPU/RAM to one machine
Simple, no code changes
Hard limit: biggest machine available
Single point of failure remains
Horizontal Scaling (Scale Out):
Add more machines, distribute load
Theoretically unlimited scale
Requires stateless services, shared storage
More complex operationally
When to go vertical first: Small teams, early stage, simple systems. Vertical is simpler.
When to go horizontal: When vertical limit is hit, or when you need fault tolerance.
Stateless vs Stateful services:
Stateless: Any server can handle any request. Easy to scale horizontally.
Stateful: Server holds session/state. Sticky sessions needed. Hard to scale.
Rule: Design services to be stateless. Put state in a shared layer (DB, cache, blob store).
10. Fault Tolerance + Reliability
What it is: System's ability to continue functioning when parts fail.
WHY it exists: Everything fails. Disks fail, networks fail, data centers fail. Design assumes failure.
Key patterns:
| Pattern | What it does |
|---|---|
| Redundancy | Duplicate critical components |
| Replication | Copy data across multiple nodes |
| Failover | Automatically switch to backup |
| Circuit Breaker | Stop calling a failing service to prevent cascade |
| Retry with backoff | Retry failed requests with increasing delays |
| Bulkhead | Isolate failures so they don't spread |
Availability math:
99% uptime = 87.6 hours downtime/year
99.9% = 8.7 hours/year
99.99% = 52 minutes/year
99.999% (five nines) = 5 minutes/year
Replication types:
Synchronous: Primary waits for replica to confirm. No data loss, slower.
Asynchronous: Primary doesn't wait. Faster, but replica may lag.
Beginner mistake: Designing only the happy path. Always ask: 'What happens when the database goes down? When the cache is empty? When the queue is full?'
