Key Question

What are the fundamental architectural patterns for organizing distributed systems?

Deep Dive

Distributed systems are organized around a few recurring architectural patterns. The choice of model determines how nodes communicate, who controls state, and how the system scales under load.

1. Client-Server

One or more centralized servers provide services; clients send requests and receive responses. Servers are stateful (maintain session state) or stateless (each request is self-contained). This is the oldest and most intuitive model.

       Request (e.g., GET /users/42)
  Client ──────────────────────────►  Server
        ◄──────────────────────────
              Response (JSON)

Advantages: Centralized control makes security, auth, and data consistency straightforward. You know exactly where the data lives.

Disadvantages: Single point of failure — if the server goes down, everyone is blocked. Scalability is limited by the server’s capacity (vertical scaling hits a ceiling). A single server handling 10M users requires significant hardware.

2. Peer-to-Peer

Every node (peer) acts as both client and server. There is no central coordinator. Each peer stores and serves data, routes requests, and enforces rules collectively.

  ┌─────────┐     ┌─────────┐
  │ Peer A  │◄───►│ Peer B  │
  └─────────┘     └─────────┘
       ▲               ▲
       │               │
       ▼               ▼
  ┌─────────┐     ┌─────────┐
  │ Peer C  │◄───►│ Peer D  │
  └─────────┘     └─────────┘

Advantages: Scales horizontally — each new peer adds capacity. No SPOF. Highly fault-tolerant (the network survives node failures). Example: BitTorrent — thousands of peers sharing file chunks without any central server.

Disadvantages: Coordination is expensive (consensus, routing, discovery). Consistency is harder to enforce. Security is more complex (no central authority to ban bad actors).

3. Multi-Tier (n-Tier)

The system is split into distinct layers: presentation (UI), application logic, and data storage. Each layer can be deployed and scaled independently.

  ┌──────────────┐
  │  Browser/App │  (Presentation Tier)
  └──────┬───────┘
         │ HTTP
  ┌──────▼───────┐
  │  API Server  │  (Logic Tier)
  └──────┬───────┘
         │ SQL
  ┌──────▼───────┐
  │   Database   │  (Data Tier)
  └──────────────┘

This is the default for modern web apps. You can scale the API tier independently of the database and swap the frontend without touching the backend.

Hybrid Models

Real systems often blend patterns:

• Super-peers (Skype, early KaZaA): Most peers connect to super-peers, which form a P2P backbone. Combines P2P’s scalability with client-server’s manageability.
• Edge computing: Client devices process data locally, sync to cloud servers when connected. Like a P2P-client-server hybrid.
• Microservices: Each service is a small client-server system; collectively they form a distributed graph that behaves more like P2P internally.

Check Your Understanding

1. A team is building a real-time multiplayer game for 10,000 concurrent players. Should they use client-server or P2P? Why?

2. What are the key disadvantages of a 3-tier architecture compared to a pure P2P design?

3. Why might you combine super-peers with a P2P overlay rather than using pure P2P?

The “So What?”

Architecture is the first design decision you make in any distributed system. Pick client-server when you need strong consistency and control. Pick P2P when you need massive scale and fault tolerance. Pick multi-tier when you need to evolve and scale different parts independently. Most production systems are hybrids — the trick is knowing which pattern fits each subsystem.

✏️ Exercises

Exercises: Architectural Models & RPC

Exercise 1: Architecture Choice

A team is building a file-sharing application for 100,000 users. Files are read-heavy (mostly downloads), users are geographically distributed, and there is no budget for centralized infrastructure.

1. Which architectural model (client-server, P2P, multi-tier, hybrid) would you recommend?
2. What specific design decisions would you make to handle the read-heavy workload?
3. What are the top three problems you’d need to solve?

Exercise 2: RPC Call Failure Analysis

A client calls deductBalance(userID: "u42", amount: 50.00) via RPC. The client stub sends the request to the server. For each scenario below, state what happens and whether the client’s balance is correct:

1. The client stub marshals the request and sends it. The server receives it, unmarshals, calls the function (which deducts $50 from the DB), but the server crashes before sending the response.
2. The server receives the request, processes it, and sends the response. The response is lost in the network. The client times out and throws an exception.
3. The client sends the request. The server processes it and sends the response. The client receives the response. Everything works — but the network duplicates the request and the server processes it twice.

Exercise 3: Protobuf Field Evolution

You have this protobuf schema deployed in production:

message Order {
  string order_id = 1;
  string user_id = 2;
  float total = 3;
}

You want to add a string coupon_code = 4 field. Some old server instances still running don’t know about field 4.

1. Will old servers crash when they receive a message with coupon_code set?
2. A client built from the old schema processes a message that has coupon_code. What does the client see?
3. What happens if you later delete field 3 (total) and reuse its number for a new int64 total_cents = 3?