Distributed Systems & Concurrency: Overview

Introduction: The “Multiple Brain” Problem

In a single-machine world, the CPU knows everything. In a Distributed System, you have hundreds of “brains” (servers) that must work together.

• What if the network splits and Server A can’t talk to Server B?
• What if 10,000 users buy the last iPhone at the exact same millisecond?

This chapter covers the algorithms that keep the internet running reliably, even when things fail.

Typical Business Scenarios

• Financial Transactions: Ensuring money is never “created” or “lost” during a transfer between two different database shards (2PC, Paxos).
• Cloud Coordination: Ensuring all nodes in a cluster agree on who the “Leader” is (Raft).
• API Protection: Preventing a single user from crashing your system with 1M requests (Rate Limiting).
• System Stability: Automatically cutting off traffic to a failing microservice to prevent a total meltdown (Circuit Breaker).

Core Concepts: The CAP Theorem

You cannot have all three:

1. Consistency (C): Every node sees the same data at the same time.
2. Availability (A): Every request receives a response (even if it’s old data).
3. Partition Tolerance (P): The system continues to work even if the network fails.

The Reality: In the cloud, network failure (P) is inevitable. You must choose between Consistency (Raft/Paxos) or Availability (Gossip/Eventual Consistency).

Quick Look at Common Algorithms

• 5.1 Raft: The “Understandable” consensus algorithm used by etcd and Kubernetes.
• 5.3 2PC (Two-Phase Commit): The classic way to handle atomic transactions across databases.
• 5.5 Rate Limiting: Token Bucket and Leaky Bucket algorithms for traffic control.
• 5.6 Circuit Breaker: The “Safety Fuse” for microservices.
• 5.8 Vector Clocks: Tracking the order of events when there is no global clock.

Selection Cheat Sheet

The “One-Sentence Mindset”

“Distributed algorithms turn a chaotic network of failing machines into a single, reliable virtual computer.”