Why System Design Matters

The Journey from Class to System

You’ve written a beautiful class. It’s well-designed, follows SOLID principles, and has great test coverage. But software doesn’t run in isolation—it runs on servers, handles thousands of users, and must work 24/7.

The Big Picture

Your class is just one piece of a larger puzzle. System design helps you understand the puzzle, so you can build pieces that fit perfectly.

---

What is System Design?

System design is the process of defining the architecture, components, and data flow of a system to meet specific requirements. It’s about making decisions that affect:

• How your code runs - On one server or thousands?
• How data flows - Synchronous or asynchronous?
• How failures are handled - What happens when things break?
• How the system scales - Can it handle 10x more users?

The Two Levels of Design

Aspect	High-Level Design (HLD)	Low-Level Design (LLD)
Focus	System architecture	Class structure
Scope	Multiple services	Single service/module
Artifacts	Architecture diagrams	Class diagrams
Decisions	Which database? How many servers?	Which pattern? What interface?
Scale	Millions of users	Thousands of objects

---

Why LLD Engineers Need System Design

1. Your Code Doesn’t Run in Isolation

Every class you write will eventually run in a system with:

Python

order_service.py

class OrderService:
    """Looks simple, but consider the system context..."""

    def __init__(self, db: Database, payment: PaymentGateway, inventory: InventoryService):
        self.db = db                    # Which database? Replicated? Sharded?
        self.payment = payment          # External API - what if it's slow?
        self.inventory = inventory      # Another service - what if it's down?

    def place_order(self, order: Order) -> OrderResult:
        # What if this takes 30 seconds?
        # What if 1000 users call this simultaneously?
        # What if the database is in another data center?

        self.inventory.reserve(order.items)   # Network call #1
        payment_result = self.payment.charge(order.total)  # Network call #2
        self.db.save(order)  # Network call #3

        return OrderResult(success=True, order_id=order.id)

Java

OrderService.java

public class OrderService {
    // Looks simple, but consider the system context...

    private final Database db;           // Which database? Replicated? Sharded?
    private final PaymentGateway payment; // External API - what if it's slow?
    private final InventoryService inventory; // Another service - what if it's down?

    public OrderService(Database db, PaymentGateway payment, InventoryService inventory) {
        this.db = db;
        this.payment = payment;
        this.inventory = inventory;
    }

    public OrderResult placeOrder(Order order) {
        // What if this takes 30 seconds?
        // What if 1000 users call this simultaneously?
        // What if the database is in another data center?

        inventory.reserve(order.getItems());   // Network call #1
        PaymentResult paymentResult = payment.charge(order.getTotal());  // Network call #2
        db.save(order);  // Network call #3

        return new OrderResult(true, order.getId());
    }
}

Hidden Complexity

That simple placeOrder method makes 3 network calls. Each can fail, timeout, or be slow. Without system design knowledge, you won’t anticipate these issues in your LLD.

2. Design Decisions Have System Implications

Every LLD decision affects the system:

LLD Decision	System Implication
Using Singleton pattern	Won’t work across multiple servers
Storing state in instance variables	Can’t scale horizontally
Synchronous method calls	Creates coupling, blocks resources
In-memory caching	Each server has different cache
Auto-increment IDs	Conflicts in distributed databases

3. Interviews Test Both Levels

In senior engineering interviews, expect questions like:

---

The Five Pillars of System Design

Every system design discussion involves these key concerns:

1. Scalability

Can the system handle growth?

LLD Impact: Design classes that can work in a distributed environment. Avoid global state, use dependency injection, make components stateless where possible.

2. Reliability

Does the system work correctly, even when things fail?

• Hardware fails (servers crash, disks die)
• Software has bugs
• Networks are unreliable
• Users make mistakes

LLD Impact: Implement proper error handling, use retry patterns, design for idempotency.

3. Availability

Is the system accessible when users need it?

• 99.9% uptime = 8.76 hours downtime/year
• 99.99% uptime = 52.6 minutes downtime/year
• 99.999% uptime = 5.26 minutes downtime/year

LLD Impact: Design classes with fallback behaviors, implement circuit breakers, handle graceful degradation.

4. Maintainability

Can the system be easily modified and operated?

• New features can be added
• Bugs can be fixed quickly
• Operations are simple
• System is observable

LLD Impact: Follow SOLID principles, write clean code, use design patterns appropriately.

5. Performance

Does the system respond quickly and efficiently?

• Low latency (fast responses)
• High throughput (many requests)
• Efficient resource usage

LLD Impact: Choose appropriate data structures, optimize algorithms, minimize unnecessary operations.

---

Real-World Example: A Simple Counter

Let’s see how system thinking changes a simple class design:

Version 1: The Naive Approach

Python

naive_counter.py

class PageViewCounter:
    """Simple counter - works perfectly on one server"""

    def __init__(self):
        self.counts = {}  # page_id -> count

    def increment(self, page_id: str) -> int:
        if page_id not in self.counts:
            self.counts[page_id] = 0
        self.counts[page_id] += 1
        return self.counts[page_id]

    def get_count(self, page_id: str) -> int:
        return self.counts.get(page_id, 0)

# Usage
counter = PageViewCounter()
counter.increment("homepage")  # 1
counter.increment("homepage")  # 2

Java

NaiveCounter.java

import java.util.HashMap;
import java.util.Map;

public class PageViewCounter {
    // Simple counter - works perfectly on one server
    private Map<String, Integer> counts = new HashMap<>();

    public synchronized int increment(String pageId) {
        int count = counts.getOrDefault(pageId, 0) + 1;
        counts.put(pageId, count);
        return count;
    }

    public int getCount(String pageId) {
        return counts.getOrDefault(pageId, 0);
    }
}

// Usage
public class Main {
    public static void main(String[] args) {
        PageViewCounter counter = new PageViewCounter();
        counter.increment("homepage");  // 1
        counter.increment("homepage");  // 2
    }
}

Problems with this design:

• ❌ Data lost if server restarts
• ❌ Different counts on each server
• ❌ No persistence
• ❌ Memory grows unbounded

Version 2: System-Aware Design

The key insight is to externalize state to a shared store that all servers can access. This requires:

1. Abstraction - Define an interface for storage (Dependency Inversion Principle)
2. Shared State - Use Redis, a database, or similar shared storage
3. Atomic Operations - Use Redis’s INCR command which is atomic

Python

distributed_counter.py

class PageViewCounter:
    """Counter that works in distributed systems"""

    def __init__(self, redis_client):
        self.redis = redis_client  # External shared state

    def increment(self, page_id: str) -> int:
        return self.redis.incr(f"pageview:{page_id}")  # Atomic operation

    def get_count(self, page_id: str) -> int:
        return int(self.redis.get(f"pageview:{page_id}") or 0)

# Now works across all servers!
counter = PageViewCounter(redis.Redis(host='redis-cluster'))
counter.increment("homepage")

Java

DistributedCounter.java

public class PageViewCounter {
    private final Jedis redis;  // External shared state

    public PageViewCounter(Jedis redis) { this.redis = redis; }

    public long increment(String pageId) {
        return redis.incr("pageview:" + pageId);  // Atomic operation
    }

    public long getCount(String pageId) {
        String count = redis.get("pageview:" + pageId);
        return count != null ? Long.parseLong(count) : 0;
    }
}

What changed and why:

Change	System Design Reason
Added CounterStorage interface	Decouples from specific storage (DIP)
Used Redis instead of in-memory	Shared state across servers
Dependency injection	Testable, flexible, swappable
Atomic operations (INCR)	Handles concurrent requests

LLD ↔ HLD Connection

The system requirement (distributed counting) drove the LLD decisions (interface + Redis implementation). This is how HLD and LLD work together.

---

Key Takeaways

Remember

• System design is about building systems that work reliably at scale
• LLD and HLD are connected - system constraints affect class design
• Five pillars: Scalability, Reliability, Availability, Maintainability, Performance
• Every class eventually runs in a system with users, networks, and failures
• Think ahead - design classes that can evolve with system requirements

---

What’s Next?

Now that you understand why system design matters, let’s dive into the first fundamental concept:

Next up: Scalability Fundamentals - Learn how systems grow and the strategies to handle that growth.

Practice Mindset

As you design classes, always ask: “What if there were 1000 of these running on different servers?” This mindset will make you a better engineer.