Distributed System Architectures & Models

System Architecture

What is “System Architecture”?

System architecture defines how a system is structured. This involves three things:

• Identify components: what pieces make up the system (clients, servers, middleware, data, etc.).
• Define functions of each component: what each part is responsible for.
• Define relationships and interactions: how components communicate and depend on each other.

Think of this as the “blueprint” of a distributed system.

Architectural Styles (Big Idea)

Core idea:

First, organize the system into logically different components, then decide how to distribute those components across machines.

Two main styles shown:

Layered Style (typical in client-server systems)

• You have stacked layers: Layer 1 → Layer 2 → ... → Layer N.
• Requests flow down through layers.
• Responses flow up through layers.

Typical meaning:

• Each layer provides services to the layer above it.
• Each layer hides details from higher layers.
• Changes in one layer ideally don’t break others.

Example intuition:

• Application → Middleware → Network → OS

Object-based Style (typical in service-oriented architectures)

• System is composed of objects/services that directly call each other.
• There is no strict top-to-bottom layering.
• Objects interact via method calls / messages.

This is closer to:

• Microservices
• RPC-based systems
• Distributed object systems

Layers in a Distributed System

Three conceptual layers:

Platform (bottom layer)

• Provides fundamental services:
  • Communication (networking)
  • Resource management (CPU, memory, storage)
• Usually handled by the OS and network stack.
• Applications typically don’t deal with this directly.

Middleware (middle layer)

• Sits between platform and applications.
• Hides heterogeneity (different machines, networks, OSes).
• Provides an “easier” API for distributed programming.
• Example: RPC (Remote Procedure Call), message queues, etc.

Applications (top layer)

• Actual distributed applications and services:
  • Email
  • FTP
  • Web services
  • Cloud applications

System Architectures

Three major types are discussed:

Client-Server Architecture

Variants:

• Multiple clients / single server
• Multiple clients / multiple servers
• Mobile clients
• Thin clients (minimal local processing)

Basic idea:

• Clients send requests.
• Server processes and returns results.

Client-Server Timing:

• Client sends a request.
• Server processes (“Provide service”).
• Client waits.
• Server replies.

Multiple-Client / Single-Server

Key issues:

• Server becomes a bottleneck (limits performance).
• Single point of failure (if server crashes, system fails).
• Hard to scale (adding more clients overloads the server).

Multiple Clients / Multiple Servers

• Clients connect to a network.
• Multiple servers exist, each with its own data store.
• Clients can talk to different servers.
• This improves:
  • Scalability
  • Fault tolerance
  • Load distribution

This is closer to modern cloud systems.

A Service Across Multiple Servers

This is a subset (refinement) of Multiple Clients / Multiple Servers, which is something more specific.

• A single logical “service” may be implemented by multiple physical servers.
• A client might:
  • Talk to one server.
  • That server may communicate with other servers to fulfill the request.

This represents:

• Load balancing
• Replication
• Distributed backends

Multiple-Client / Multiple-Server Communication

This is a specific way of realizing “A Service Across Multiple Servers.”

• Multiple clients send requests to a middle server.
• That server then invokes other backend servers.
• Results propagate back to clients.

Key point:

• There is often an intermediate service (gateway, coordinator, or API server).
• This is common in:
  • Microservices
  • Distributed databases
  • Cloud applications

“Thin Clients”

What is a thin client?

• A thin client runs only the user interface (GUI) locally.
• The actual application logic and computation run on a remote compute server.

Key characteristics

• Client does minimal processing.
• Most work (computation, storage, application execution) happens on the server.
• Client mainly sends user inputs and displays results.

Examples (historical / real-world)

• X11 systems (graphics rendered remotely).
• Early devices like Palm Pilots.
• Conceptually similar to modern remote desktops or cloud apps.

Big idea

• Good when clients are weak (low power, mobile, or limited hardware).
• Shifts complexity and cost to centralized servers.

Multitier Systems

Overall idea

• Organize a complex system into three logical layers:
  1. User-interface level
  2. Processing level
  3. Data level

Search Engine Example

(a) User-interface level (top)

What the user sees and interacts with:

• User enters a keyword expression (search query).
• System returns an HTML page containing a ranked list of results.

Components here:

• “User interface” (e.g., web page or browser front end).

(b) Processing level (middle)

This is where most logic happens:

1. Query generator
   • Takes the user’s keywords.
   • Translates them into database queries.
2. Ranking component
   • Receives page titles + metadata from the database.
   • Ranks results (e.g., relevance, popularity).
3. HTML generator
   • Takes ranked results.
   • Formats them into an HTML results page for the user.

Flow: User query → Query generator → Database

Database → Ranking component → HTML generator → User

(c) Data level (bottom)

• A database containing:
  • Web pages
  • Page titles
  • Metadata (keywords, links, etc.)

This is the persistent storage layer that supports the search engine.