System design: Distributed Systems Fundamentals

As technology evolves and systems scale, applications often outgrow the capacity of single servers. Distributed systems come into play when we need to scale beyond the capabilities of individual machines and ensure availability, scalability, and fault tolerance across a network of computers. In this chapter, we'll dive into the basics of distributed computing, the complexities of coordination in distributed systems, consensus algorithms like Paxos and Raft, and the mechanisms of distributed data storage and replication.

Basics of Distributed Computing

What is Distributed Computing?

Distributed computing refers to a system in which multiple independent computers (or nodes) work together to achieve a common goal. These systems typically span across multiple locations and can be made up of different machines like servers, virtual machines, or even edge devices. Each machine handles a subset of the total workload, and together, they form a cohesive unit.

Key Characteristics of Distributed Systems

Decentralization: No single machine is responsible for all tasks; instead, each node contributes to the system’s overall functionality.
Scalability: Distributed systems can handle a growing amount of work by adding more nodes to the network.
Fault Tolerance: If one machine fails, others can continue to function, ensuring that the system remains operational.
Concurrency: Multiple tasks are executed in parallel, enabling faster processing and more efficient use of resources.
Latency: Communication between nodes is slower compared to a single-machine system because of network overhead, which can introduce latency in data sharing and coordination.

Practical Examples:

Cloud Computing: AWS, Google Cloud, and Azure are prime examples of distributed systems. These cloud providers distribute data storage and computation across data centres worldwide.
Content Delivery Networks (CDN): Services like Akamai or Cloudflare distribute content globally to ensure fast delivery by caching content across many servers close to users.

Coordination in Distributed Systems

Challenges in Coordination

In distributed systems, coordination between nodes is one of the most complex aspects. Unlike in single-machine systems, where everything is controlled in one place, distributed systems must synchronize between different nodes to maintain consistency and ensure smooth operations.

Key coordination challenges include:

Data Consistency: Ensuring that all nodes have the same version of data at any given time, even in the event of failures.
Synchronization: Nodes must work together to complete tasks. Ensuring that each node knows what the other nodes are doing is critical to avoid conflicts or duplication of work.
Failures: Since nodes can fail at any time, the system must continue to function without compromising overall reliability.

Coordination Mechanisms:

Leader Election: In many distributed systems, one node is chosen as the leader to coordinate tasks among other nodes. For example, in a distributed database, one node might be elected to handle write operations to avoid conflicts.
Locking and Mutual Exclusion: When multiple nodes need to access the same resource, distributed locking mechanisms (like ZooKeeper) help to ensure that only one node can access the resource at a time.
Heartbeats and Health Checks: Nodes regularly send signals (heartbeats) to show that they are alive. If a node fails to send a heartbeat within a specified interval, the system can trigger failover mechanisms.

Practical Example: Distributed Locking with ZooKeeper

ZooKeeper is a distributed coordination service used by many systems to manage configuration, synchronization, and naming. In a microservices architecture, you can use ZooKeeper to ensure that only one service instance acts as the leader, or to create distributed locks that prevent two services from making conflicting changes to shared resources.

Consensus Algorithms (Paxos, Raft, etc.)

The Need for Consensus

In distributed systems, multiple nodes often need to agree on a particular value or state — for example, the order of transactions in a database or which node should be the leader. However, achieving consensus in distributed environments is complicated by network delays, node failures, and the lack of a central authority. This is where consensus algorithms come in.

Paxos Algorithm

Overview: Paxos is one of the earliest and most well-known consensus algorithms, designed to help distributed systems agree on a single value, even in the face of node failures and unreliable communication.
How It Works: Paxos operates in three phases:
- Prepare: A proposer sends a proposal to a set of nodes (acceptors) asking them to promise not to accept proposals with a lower number than the one being proposed.
- Promise: The acceptors respond with a promise that they won’t accept lower-numbered proposals. They also share any previously accepted values.
- Accept: If the proposer receives enough promises, it sends an "accept" message with its proposed value. The acceptors then update their state.
Challenges: While Paxos ensures consensus, it’s known for being challenging to implement and understand due to its complexity.

Raft Algorithm

Overview: Raft is a consensus algorithm designed to be easier to understand and implement compared to Paxos. Raft divides consensus into three distinct components: leader election, log replication, and safety.
Leader Election: One of the nodes is elected as the leader, and all changes go through the leader to ensure consistency.
Log Replication: The leader receives updates from clients and replicates them to the other nodes (followers). Once a majority of nodes acknowledge the change, it is considered committed.
Safety: Raft ensures that once a log entry is committed, it cannot be overwritten or lost.
Practical Example: Etcd and Consul, widely used in microservices architectures for service discovery and distributed configuration, both use the Raft algorithm for leader election and consistency.

Practical Uses of Consensus Algorithms:

Distributed Databases: Consensus algorithms are used to ensure that all replicas of a database have the same state, even in the event of network partitions or node failures.
Service Discovery: In microservices architectures, consensus algorithms help manage service discovery mechanisms, ensuring that all services agree on which nodes are responsible for which tasks.

Distributed Data Storage and Replication

Distributed Data Storage

When a single machine can no longer store or manage the growing amount of data, you need distributed data storage. This involves storing data across multiple machines (nodes), each responsible for a subset of the data.

Challenges in Distributed Data Storage:

Data Consistency: Keeping the same version of data across all nodes is challenging, especially in cases where nodes can fail or become disconnected.
Partitioning: Breaking data into smaller pieces and distributing it across nodes (e.g., horizontal partitioning) is necessary for scaling, but deciding how to partition the data efficiently is tricky.

Replication

Replication refers to making copies of the same data across different nodes to ensure fault tolerance and availability. If one node fails, another can take over, ensuring the system remains operational.

Types of Replication:

Synchronous Replication:
- In synchronous replication, data is copied to multiple nodes immediately. When a client writes data, the write is considered successful only after all replicas acknowledge the operation.
- Use Case: Synchronous replication ensures strong consistency, but it can introduce latency, especially in geographically distributed systems.
- Practical Example: In a banking system, synchronous replication ensures that the account balance remains consistent across different data centres.
Asynchronous Replication:
- In asynchronous replication, the primary node processes the write and returns success immediately, while replication to secondary nodes happens in the background.
- Use Case: Asynchronous replication improves performance but risks temporary inconsistencies if the primary node fails before replication completes.
- Practical Example: Social media platforms may use asynchronous replication for user posts, where a slight delay in propagation is acceptable.

Practical Example: Distributed File Storage with HDFS

The Hadoop Distributed File System (HDFS) is a widely used distributed storage system that splits files into blocks and stores them across multiple nodes. Each block is replicated to ensure fault tolerance. If a node fails, the system automatically replicates the block to another node to maintain the desired replication factor.

Replication and the CAP Theorem:

Replication is closely tied to the CAP Theorem, which states that distributed systems can only provide two out of the following three guarantees:

Consistency: All nodes see the same data at the same time.
Availability: Every request receives a response, even if some nodes fail.
Partition Tolerance: The system continues to operate even if communication between nodes is interrupted.

In practice, systems often choose between consistency and availability, depending on the use case. For example, banking systems prioritize consistency, while social media systems might favour availability.

Bringing It All Together

Distributed systems introduce complexity that doesn’t exist in single-node applications, but they also offer the ability to scale, provide fault tolerance, and improve performance. By understanding the fundamentals of coordination, consensus algorithms, and distributed data storage, you can design robust, scalable systems that meet the demands of modern applications.