Distributed System Architectures & Communication Models

TAKEAWAYS:

• Distributed systems are classified into client-server, peer-to-peer, and hybrid architectures, each with distinct communication patterns and scalability trade-offs.
• Communication models (synchronous, asynchronous, transient, persistent) determine how processes exchange messages, affecting latency, reliability, and complexity.
• Transient synchronous communication (e.g., HTTP requests) requires immediate acknowledgments, while persistent asynchronous (e.g., email) tolerates delays.
• Addressing and naming (logical vs. physical names, identifiers) enables unique process identification and location transparency.
• Network topologies (star, mesh, hybrid) influence communication efficiency and fault tolerance in distributed systems.
• Real-world examples: eSewa’s client-server model, Daraz’s asynchronous order processing, and NTC’s mesh-like network for redundancy.

1. Introduction to Distributed System Architectures

Distributed systems organize processes across multiple nodes to achieve scalability, fault tolerance, and performance. The architecture defines how these nodes interact, while the communication model dictates how they exchange data.

1.1 Classification of Distributed System Architectures

Distributed systems are broadly categorized into three architectures:

mindmap
  root((Distributed System Architectures))
    Client-Server
      - Centralized control (e.g., eSewa backend)
      - Scalable but single point of failure
      - Example: Bank ATMs (clients) ↔ Bank servers
    Peer-to-Peer (P2P)
      - Decentralized (e.g., BitTorrent, early WhatsApp)
      - No central authority; nodes share resources
      - Example: Pathao drivers ↔ riders (shared ride matching)
    Hybrid
      - Combines client-server and P2P (e.g., modern WhatsApp)
      - Central servers for authentication + P2P for messaging

Comparison Table:

1.2 Key Characteristics of Each Architecture

• Client-Server:

  • Advantages: Easy to manage, centralized security, predictable performance.
  • Disadvantages: Single point of failure, scalability bottlenecks.
  • Real-world: eSewa uses client-server for transaction processing. The server validates payments, while users (clients) request transfers. If the server crashes, all transactions halt—highlighting the need for redundancy (e.g., backup servers).

• Peer-to-Peer:

  • Advantages: No single bottleneck, resilient to node failures.
  • Disadvantages: Harder to manage, security risks (e.g., Sybil attacks).
  • Real-world: Daraz’s order processing initially used P2P for seller-buyer matching. Sellers (peers) directly communicate with buyers, reducing server load. However, Daraz later introduced a hybrid model to handle authentication centrally.

• Hybrid:

  • Advantages: Balances control and scalability.
  • Disadvantages: Complex to design.
  • Real-world: NTC’s network uses hybrid architecture. Central nodes manage routing, while edge nodes (peers) handle local traffic, reducing latency.

2. Communication Models in Distributed Systems

Communication defines how processes interact. The model affects latency, reliability, and resource usage.

2.1 Types of Communication

Distributed systems use four primary communication models:

mindmap
  root((Communication Models))
    Synchronous
      - Immediate response required (e.g., HTTP GET)
      - Example: User clicks "Pay" on eSewa → server responds instantly
    Asynchronous
      - No immediate response (e.g., email, Kafka)
      - Example: Daraz order → seller notified later
    Transient
      - Message lost if not acknowledged (e.g., UDP)
      - Example: Real-time gaming (low latency > reliability)
    Persistent
      - Messages stored until delivered (e.g., SMTP, MQTT)
      - Example: WhatsApp messages (retry until delivered)

Worked Example: Daraz Order Processing

1. Asynchronous Model:

   • A buyer places an order → Daraz’s system logs it but doesn’t immediately notify the seller.
   • The seller checks the order later via their dashboard (asynchronous callback).
   • Why? Reduces server load; sellers process orders in batches.

2. Synchronous Model (for critical steps):

   • Payment verification: The buyer’s payment request → Daraz server → bank → response within 2 seconds (synchronous).

2.2 Transient vs. Persistent Communication

Visual: Transient Synchronous Communication

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: Request (e.g., "Check stock")
    Server-->>Client: Response (200 OK)
    note right of Client: **Transient Synchronous**
    note right of Server: Message may be lost if not acknowledged
    note right of Client: Example: NTC’s VoIP calls (low latency, unreliable)

Use case: eSewa’s "Check Balance" API. The client (mobile app) sends a request, and the server must respond within 1 second or the user abandons the transaction.

2.3 Addressing and Naming in Distributed Systems

Processes need unique identifiers and addresses to communicate. Key terms:

• Identifier (ID): Unique name (e.g., user123).
• Address: Location (e.g., 192.168.1.10:8080).
• Name: Human-readable alias (e.g., eSewaBank).

Types of Communication:

1. Direct Communication: Process A sends to Process B’s address.
   • Example: Two Daraz sellers chatting via their IDs.
2. Indirect Communication: Via a message queue (e.g., Kafka).
   • Example: NTC’s network routers forward packets without knowing endpoints.
3. Group Communication: One-to-many (e.g., broadcast).
   • Example: Ncell’s emergency SMS to all users in a zone.

Real-world Tie-In: NTC’s Network

• Naming: Phones are named by IMSI (International Mobile Subscriber Identity).
• Addressing: Packets are routed via IP addresses (e.g., 203.101.x.x).
• Communication: Asynchronous (SMS) + synchronous (VoIP calls).

3. Network Topologies in Distributed Systems

Topology defines how nodes are connected, affecting performance, fault tolerance, and cost.

mindmap
  root((Network Topologies))
    Star
      - Central hub (e.g., NTC’s base stations)
      - Example: School Wi-Fi (router ↔ devices)
    Mesh
      - Every node connected to others (e.g., military networks)
      - Example: NTC’s backup routes for redundancy
    Hybrid
      - Combines star and mesh (e.g., modern ISPs)
      - Example: Ncell’s 5G towers (star) + fiber backhaul (mesh)

Comparison Table:

4. Real-World Applications and Worked Example

4.1 eSewa: Client-Server Architecture

• Architecture: Client-server (users ↔ payment servers).
• Communication: Synchronous (real-time transactions) + asynchronous (email receipts).
• Topology: Star (central servers ↔ users).
• Why? Centralized control ensures security (e.g., fraud detection) but requires redundancy (e.g., backup servers in Kathmandu and Pokhara).

4.2 Daraz: Hybrid Communication

• Order Processing:
  1. Buyer submits order → asynchronous (logged, no immediate seller notification).
  2. Seller checks order → synchronous (real-time stock check).
  3. Payment → synchronous (bank verification).
• Topology: Hybrid (central servers for auth + P2P for seller-buyer chats).

4.3 NTC: Mesh-Like Redundancy

• Topology: Hybrid (star for user access + mesh for backbone).
• Fault Tolerance: If one fiber cable fails, traffic reroutes via alternative paths.
• Communication: Asynchronous (SMS) + synchronous (VoIP).

5. Exam Tips for Unit 2

1. Define and Compare Architectures:

   • Always include pros/cons and real-world examples (e.g., eSewa vs. Daraz).
   • Example answer:

     Client-server is centralized (e.g., eSewa), while P2P is decentralized (e.g., early WhatsApp). Hybrid (e.g., Ncell) combines both for scalability.

2. Draw Communication Models:

   • For synchronous/asynchronous, use sequence diagrams (as shown above).
   • For transient/persistent, highlight message storage (e.g., "Message lost if not ACK’d" for transient).

3. Addressing and Naming:

   • Link IDs, addresses, and names to real systems:

     In NTC, the IMSI is the identifier, the IP address is the location, and the phone number is the name.

4. Topologies:

   • Relate to fault tolerance and scalability:

     Mesh topologies (e.g., NTC’s backbone) improve redundancy but increase cost.

5. Worked Example:

   • Trace a real scenario (e.g., Daraz order) through architecture → communication → topology.
   • Example:

     A Daraz order uses hybrid architecture: synchronous for payment, asynchronous for seller notification, and hybrid topology for server-seller communication.

6. Common Pitfalls:

   • Avoid vague answers. Always specify:
     • Which architecture? (Client-server, P2P, hybrid).
     • Which communication model? (Synchronous/asynchronous/transient/persistent).
     • Why? (Scalability, fault tolerance, latency).

In the Real World

1. eSewa (Client-Server + Synchronous Communication)

   • Idea: Uses client-server architecture for transaction processing.
   • How: Users (clients) send requests to eSewa’s centralized servers. The server validates payments in real-time (synchronous communication).
   • Why it matters: Ensures security (centralized fraud detection) but requires high server availability (e.g., backup servers in Pokhara).

2. Daraz (Hybrid Architecture + Asynchronous Processing)

   • Idea: Combines client-server (authentication) and P2P (seller-buyer chats).
   • How: Orders are processed asynchronously (sellers notified later), while payments use synchronous verification.
   • Why it matters: Reduces server load during peak hours (e.g., Dashain sales).

3. NTC (Mesh Topology + Asynchronous Communication)

   • Idea: Uses mesh-like redundancy in its backbone for fault tolerance.
   • How: If a fiber cable fails, traffic reroutes via alternative paths (asynchronous failover).
   • Why it matters: Ensures 99.9% uptime for voice/data services.

Visual Summary