System Design Interview Framework

Requirement Clarification and Scope Definition

The first step in any system design session is to acknowledge that requirements are inherently ambiguous. You must clarify the scope to prevent 'over-engineering' or solving the wrong problem entirely. By asking about functional requirements (what the system does) and non-functional requirements (how the system behaves), you establish boundaries. Consider throughput, latency, and consistency requirements early. If you do not define these, you cannot justify your choice of database or load balancing strategy later. This phase is not just about gathering facts; it is about demonstrating to the interviewer that you value business constraints and prioritize user experience. Always assume that if you don't ask about traffic volume or read/write ratios, you are flying blind. This structure ensures you have a clear target before you start sketching out components or debating specific protocols, which is vital for maintaining a logical flow throughout the interview process.

def estimate_traffic(daily_active_users, requests_per_user):
    # Calculate total daily requests to determine throughput needs
    total_requests = daily_active_users * requests_per_user
    # Convert daily to per-second (QPS) for load balancing logic
    qps = total_requests / (24 * 3600)
    return qps # Returns requests per second

High-Level Architecture and Data Flow

Once the constraints are established, the next logical step is to map out the high-level components. This is the 'bird's eye view' where you demonstrate how data moves from the client, through the network boundary, to your storage layer. By sketching the relationship between load balancers, web servers, and databases, you are building the skeleton of your system. It is critical to articulate the 'why' behind each component. For instance, you should use a load balancer not just to handle volume, but to enable horizontal scaling and provide health checks. Without this high-level map, your later discussion of specific database schemas or caching layers will seem disconnected and haphazard. Focus on clarity; if your diagram is too complex, you lose the interviewer. Keep it simple enough to be understood, but precise enough to show you understand how different layers interact under load, which is the hallmark of a senior-level system design approach.

class LoadBalancer:
    def __init__(self, servers):
        self.servers = servers # List of backend instance addresses

    def get_next_server(self, request_id):
        # Round-robin selection for even load distribution
        idx = request_id % len(self.servers)
        return self.servers[idx]

Data Modeling and Storage Selection

The storage layer is usually the bottleneck in any distributed system, so choosing the right database is critical to success. You must weigh the trade-offs between consistency and availability, as defined by the CAP theorem. If your system requires ACID compliance for financial transactions, a relational database is your primary candidate. Conversely, if your system involves massive, unstructured data with high write throughput, a non-relational key-value store might be superior. Your data schema should reflect your access patterns. Think about how you partition your data—whether through sharding based on user ID or geographical location—to ensure that no single node becomes a hot spot. This reasoning demonstrates maturity; you are not just choosing a tool because it is popular, but because it satisfies the latency and consistency profiles defined in the initial requirement gathering phase. Documenting these trade-offs is essential to show that you understand the underlying costs of your technical choices.

class ShardedDatabase:
    def __init__(self, shards):
        self.shards = shards # Dict mapping shard_id to database connection

    def save(self, user_id, data):
        # Sharding based on user_id to ensure horizontal scalability
        shard_id = hash(user_id) % len(self.shards)
        self.shards[shard_id].insert(data)

Optimizing for Latency and Performance

After the core components are laid out, you must address performance bottlenecks. This is where you introduce caching, content delivery networks, and asynchronous processing. Caching is not a magical cure-all; you must reason about cache invalidation strategies, such as write-through or write-back, and decide what constitutes acceptable staleness in your data. By introducing queues, you decouple services, allowing your system to handle bursts of traffic without failing. This approach shifts the design from a synchronous, fragile chain of dependencies to a robust, event-driven architecture. Explain your decisions by referencing the user experience—for example, lowering latency by serving frequently accessed data from an in-memory layer rather than querying the persistent database every time. This section proves you can think about the system at scale, anticipating where performance degradation occurs and implementing the necessary guardrails to protect the system's overall health and responsiveness.

class Cache:
    def __init__(self, capacity):
        self.data = {}
        self.capacity = capacity

    def put(self, key, value):
        # Evicting the oldest items to keep memory footprint bounded
        if len(self.data) >= self.capacity:
            self.data.pop(next(iter(self.data)))
        self.data[key] = value

Handling Fault Tolerance and Monitoring

The final stage involves preparing for inevitable failure. Distributed systems are inherently unreliable, and your design must account for node crashes, network partitions, and partial outages. Discuss how you implement redundancy, such as multi-region deployments or secondary database replicas, to ensure high availability. Furthermore, you must define how you observe the system. Monitoring is not just an afterthought; it is a critical component for debugging and maintenance. By discussing metrics like error rates, request latency percentiles, and resource utilization, you show that you care about the long-term operability of the system. This reasoning separates a developer who 'makes it work' from an engineer who 'keeps it running.' A well-designed system is one that degrades gracefully under pressure. By the end of this phase, you should be able to confidently explain how your system maintains state and consistency even when individual components fail, completing the cycle of robust design.

class HealthMonitor:
    def __init__(self, nodes):
        self.nodes = nodes

    def check_status(self):
        # Periodic heartbeat check to identify and remove failing nodes
        return [node for node in self.nodes if node.is_healthy()]

Interview questions

All System Design interview questions →

Check yourself

Take the full System Design quiz →