Distributed Systems: Definitions, Models & Network Fundamentals

What is a Distributed System?

A distributed system is a collection of independent computers (nodes) that appear to users as a single coherent system. These nodes communicate via a network to achieve a common goal, such as sharing resources, processing data, or providing services.

Key Characteristics

mindmap
  root((Distributed System Characteristics))
    Decentralized["No single point of control"]
    Transparency["Users see a single system, not individual nodes"]
    Openness["Nodes can join/leave dynamically"]
    Scalability["Easily add more nodes for performance"]
    Fault-Tolerance["System continues if some nodes fail"]
    Concurrency["Multiple operations happen simultaneously"]
    Heterogeneity["Nodes may use different hardware/OS"]

Why does this matter? In Nepal, services like eSewa (online payment) or Ncell’s cloud services rely on distributed systems to handle thousands of transactions per second without crashing. If one server fails, others take over seamlessly.

Centralized vs. Distributed Systems

Real-world tie-in:

• Nepal Electricity Authority (NEA) uses a centralized system for billing, which can crash during peak hours. A distributed approach (like eSewa’s payment system) would handle surges better.

Architectural Models

1. Client-Server Model

How it works:

• Client (e.g., your laptop) sends a request (e.g., "Load YouTube video").
• Server (e.g., Google’s servers) processes the request and sends back the video stream.
• Example: When you use WhatsApp, your phone (client) communicates with WhatsApp’s servers (server) to send/receive messages.

Advantages:

• Simple to implement.
• Centralized management (easier updates).
• Scalable (add more servers for load balancing).

Disadvantages:

• Single point of failure (if the server crashes, the system fails).
• Bottleneck at the server during high traffic (e.g., NEPSE’s website during stock market hours).

2. Peer-to-Peer (P2P) Model

graph TD
    A["Peer 1"] -->|"File Request"| B["Peer 2"]
    B -->|"File Share"| A
    C["Peer 3"] -->|"Download"| B

How it works:

• All nodes (peers) are equal; no dedicated server.
• Peers share resources (e.g., files, bandwidth) directly.
• Example: BitTorrent (used for large file downloads) or Khalti’s decentralized payment verification (where multiple nodes validate transactions).

Advantages:

• No single point of failure.
• Cost-effective (no need for expensive servers).
• Scalable (more peers = more resources).

Disadvantages:

• Harder to manage (security, synchronization).
• Performance depends on peer availability (e.g., slow downloads if few peers are online).

Network Fundamentals

Layers and Protocols

Distributed systems rely on networks to communicate. Networks are organized into layers (like the OSI model or TCP/IP model) to simplify design.

Key Layers for Distributed Systems:

1. Transport Layer (TCP/UDP):
   • Ensures data reaches the destination.
   • TCP (reliable, connection-oriented) is used for email (SMTP) or file transfers (FTP).
   • UDP (fast, unreliable) is used for video streaming (YouTube) or online gaming.
2. Network Layer (IP):
   • Handles addressing and routing (e.g., IP addresses like 192.168.1.1).
   • Example: When you visit Daraz, your request is routed via IP addresses to Daraz’s servers worldwide.

Protocols: How Nodes Communicate

Protocols are rules that define how data is exchanged. Two critical protocols:

1. HTTP/HTTPS (Web):
   • Used for eSewa’s website or Google Search.
   • HTTPS adds encryption for security (e.g., when you pay via Khalti).
2. DNS (Domain Name System):
   • Translates human-readable names (e.g., google.com) to IP addresses.
   • Example: When you type daraz.com.np, DNS finds its IP (e.g., 104.24.114.15).

Mermaid Sequence Diagram for DNS Lookup:

sequenceDiagram
    User->>Browser: Types "daraz.com.np"
    Browser->>Local DNS: Query
    Local DNS-->>Browser: "Don't know, ask root DNS"
    Browser->>Root DNS: Query
    Root DNS-->>Browser: "Ask .np DNS"
    Browser->>NP DNS: Query
    NP DNS-->>Browser: "Ask Daraz's DNS"
    Browser->>Daraz DNS: Query
    Daraz DNS-->>Browser: "IP: 104.24.114.15"
    Browser->>User: Loads Daraz website

Real-World Applications in Nepal

1. eSewa (Online Payments):
   • Uses a distributed client-server model where your phone (client) communicates with eSewa’s servers (server) to process payments.
   • Why distributed? If one server fails, others handle the load (e.g., during Dashain/Tihar when transactions spike).

2. Ncell’s Cloud Services:

   • Ncell uses distributed databases to store customer data across multiple servers in Kathmandu and Pokhara.
   • Example: When you recharge via Ncell’s app, your request is routed to the nearest server for faster processing.

3. Nepal Stock Exchange (NEPSE):

   • Uses distributed systems to log trades across multiple servers to prevent fraud and ensure transparency.
   • Worked Example: If a trader in Kathmandu buys shares, the transaction is recorded on servers in both Kathmandu and Lalitpur simultaneously.

Worked Example: Traffic Routing in Kathmandu

Imagine Kathmandu’s traffic as a distributed network:

• Nodes: Intersections (like routers).
• Paths: Roads (like network links).
• Goal: Find the fastest route from Thapathali to Koteshwor.

How a Distributed System Would Work:

1. Your GPS app (client) sends a request to Google Maps’ servers (server).
2. The server uses distributed algorithms (like Dijkstra’s) to find the shortest path.
3. The server returns the route, and your GPS updates in real-time.
4. If one server fails (e.g., Google Maps crashes in one zone), another server takes over.

Why not centralized?

• A single traffic controller (centralized) would fail during festivals (e.g., Indra Jatra).
• Distributed systems adapt dynamically (e.g., Pathao’s ride-sharing app reroutes drivers based on real-time demand).

Challenges in Distributed Systems

1. Heterogeneity:
   • Nodes may use different OS (Windows, Linux) or hardware.
   • Solution: Use standard protocols (e.g., HTTP works on all devices).

2. Security:

   • Open networks are vulnerable to attacks (e.g., man-in-the-middle attacks on Khalti).
   • Solution: Encryption (HTTPS), firewalls, and multi-factor authentication.

3. Synchronization:

   • Ensuring all nodes have the same data (e.g., bank balances across branches).
   • Solution: Replication (copying data to multiple nodes) or consensus algorithms (like Paxos).

4. Latency:

   • Delay in communication (e.g., lag in online gaming).
   • Solution: Use edge computing (process data closer to the user, e.g., Ncell’s local data centers).

Exam Tip

This unit is conceptual but heavily tested in TU/PU exams. Focus on:

1. Definitions: Be able to explain distributed systems vs. centralized systems in one sentence.
2. Models: Compare client-server vs. P2P in a table (like above).
3. Real-world ties: Link concepts to Nepalese examples (eSewa, Ncell, NEPSE).
4. Layered models: Draw the OSI model and label TCP/IP’s role.
5. Protocols: Know HTTP/HTTPS, DNS, and UDP/TCP differences.
6. Challenges: Expect questions on security, heterogeneity, and fault tolerance.

Common Pitfalls:

• Confusing distributed systems with parallel processing (they’re not the same!).
• Forgetting to mention transparency or scalability in characteristics.
• Not linking examples to Nepal (examiners love local context).