Distributed Systems Fundamentals: Core Concepts for System Design

Understanding Distributed Systems

A distributed system comprises multiple computers working in concert to appear as a single, coherent system to users. The inherent challenges lie in coordinating across network boundaries, handling inevitable failures, and managing data spread across various locations. System design interviews often assess an engineer's ability to reason through these complexities, explicitly clarifying requirements, estimating capacity, making trade-offs, and communicating their architectural decisions.

Core Distributed System Concepts

• Scalability: The system's ability to handle increased load. It can be achieved via vertical scaling (bigger machines, limited ceiling) or horizontal scaling (more machines, higher ceiling but introduces complexity like load balancing and data partitioning).
• Reliability and Fault Tolerance: Reliability ensures the system performs as expected despite failures, while fault tolerance provides the mechanisms to continue operating. Failures (disks, networks, servers) are common in distributed systems, so designs must anticipate and build around them (e.g., Netflix's multi-region deployments, circuit breakers).
• Consistency: Defines whether all readers see the same data value at the same time across multiple data replicas. Strong consistency guarantees immediate visibility of updates but is expensive, while eventual consistency allows temporary staleness for faster operations.
• Availability: Measures how often the system is operational and responsive. High availability requires redundancy (e.g., load balancers, database replication). There's often a trade-off between availability and strong consistency.
• Partition Tolerance: The system's ability to continue operating despite network partitions, where parts of the system cannot communicate. Partitions are unavoidable in distributed environments.

The CAP Theorem: Choosing Trade-Offs

CP Systems (Consistency over Availability): Prioritize consistency. If a partition occurs, the system will refuse requests to avoid serving inconsistent data. Examples include traditional banking systems (e.g., ensuring no overdrafts) and MongoDB's default configuration for writes during primary node isolation.

AP Systems (Availability over Consistency): Prioritize availability. During a partition, both sides of the system continue serving requests, reconciling conflicts later. Social media feeds (e.g., Instagram posts appearing eventually) and Amazon DynamoDB for shopping carts are examples, where momentary staleness is acceptable for continuous service.

Many modern systems offer tunable consistency, allowing architects to select the appropriate consistency level per operation (e.g., Cassandra's `QUORUM` for stronger consistency or `ONE` for higher availability). This highlights the importance of understanding specific application requirements to make informed consistency trade-offs.

Essential Distributed Systems Patterns

• Sharding / Partitioning: Distributes data across multiple databases to scale beyond a single machine's capacity. Strategies include hash-based (e.g., by user ID for Instagram), range-based, or geographic sharding. This trades global query flexibility for horizontal scalability.
• Replication: Duplicates data across multiple servers for redundancy, fault tolerance, and read scaling. Different replication models (e.g., leader-follower) impact consistency and recovery.