System Architecture and Distributed Architectures

Objective and Context

• The lecturer aims to include at least one objective slide per lecture to highlight high points and takeaways. Some lectures will have multiple slides serving as a quick reminder of key takeouts.

• Today is definition-heavy: focus on defining what a system is, what architecture means, the environment the system exists in, and what system architecture encompasses.

• The goal is to understand how fundamental properties and patterns of relationships, connections, constraints, and environmental interactions form a system’s architecture.

Definitions: System, Boundary, Subsystems, and Environment

• System: a collection of components linked together and organized to accomplish a task, with a defined boundary that separates it from the environment.

  • Formal idea: a system is a grouping of things connected to achieve a purpose, with a boundary that differentiates the system from everything outside it.

• Subsystems: many systems contain subsystems. Example: a computer as a system with a case boundary containing multiple components, each with their own sub-systems.

  • Computer-level subsystems example:

  • CPU (central processing unit) contains subcomponents for processing instructions: decode, execute, etc.

  • Memory stores values; within memory there are cells that store data, track free space, move data between storage and CPU, etc.

• Boundary and environment:

  • The boundary is important because it distinguishes the system from the environment.

  • The environment interacts with the system in ways that differ from internal components; this external interaction is a key consideration in architecture.

System Architecture: Definition and Scope

• System architecture is the set of fundamental properties and patterns of relationships, connections, and constraints that define how the system is linked together and how it interacts with its environment.

• It answers:

  • What composes the system and what does not compose the system?

  • How do the components and non-components (non-constituents) interact?

  • What is the system’s behavior, and how do all pieces work together over time?

• The definition is lofty and abstract, but in practice it becomes clearer and more well-defined when applied to real systems.

Distributed Process Systems: Where the Action Happens

• In many real-world systems, actions occur both locally and remotely, i.e., distributed process systems.

• The most common distributed pattern is the client-server architecture, which will be discussed in detail.

• The emphasis is on how distributed architectures organize tasks across multiple devices or locations rather than a single monolithic computer.

Client-Server Architectures: Concepts and Variants

• Core idea: a client requests services or data from a server; the server provides the service or data.

• Simple example often used: a web client (your browser) requests a page from a web server (e.g., on Brightspace).

• In a typical simple flow:

  • You as a web client request a page from a web server.

  • The web server serves the page that contains data (e.g., content) but may need additional data from other services.

• Email example to illustrate multi-tier interactions:

  • A web client requests your mail page from a web server (e.g., mail.google.com or outlook.office.com).

  • The page contains mail data which the web server must retrieve from a mail server, turning a single client-server interaction into a multi-tier interaction.

  • This brings the scenario to a 3-tier architecture: client → web server → mail server (data source).

• Real-world complexity often involves many more entities; modern requests can involve around 10 different entities or services.

• Authentication and security add layers: logging in triggers credential checks and MFA (multi-factor authentication), complicating the interaction flow beyond a simple client-server model.

• Cloud computing is described as an evolved version of client-server where most work happens on the server side (in the cloud) and less on the client.

  • The term "cloud" will be revisited and clarified in a future lecture.

Two-Tier, Three-Tier, and Multi-Tier Architectures

• Dual (two-tier) architecture: two entities involved – typically a client and a server.

  • Notation: 2-tier architecture.

• Three-tier architecture: adds an intermediate server (e.g., a web server) between the client and the data source/server-side service.

  • Notation: 3-tier architecture.

  • Example flow: web client requests a page from a web server; the web server may request data from a separate mail server to populate the page (as in the mailbox example).

• In practice, modern requests can involve many more than three tiers and entities; the term "tier" is used to describe logical separation of roles and services, not just physical machines.

Cloud Computing: Evolved Client-Server Model

• Cloud computing moves more processing and data storage to remote servers, reducing the work required on the client side.

• Key idea: most or all of the work is done on the cloud/server side rather than on the client device.

• Why cloud is a "fun word": it represents a shift in where computation and data reside and how services are delivered, not a single technology.

Peer-to-Peer (P2P) Computing: Equal Partners in a Network

• P2P involves multiple peers that are equal and can both request and provide resources/services to others in the network.

• Contrast with client-server: in P2P, peers are not strictly clients or servers; they can act as both.

• Common associations:

  • P2P is often described in the context of torrenting and piracy, where files are shared across a network without a central server.

  • Even in typical downloads, many download servers may be peered together to distribute load and improve availability; this is a form of distributed sharing behind the scenes (e.g., content delivery networks rely on distributed resources).

• Practical takeaway: P2P is a premier pattern for many file-sharing and content-distribution scenarios, leveraging multiple equal participants to improve resilience and scalability.

Real-World Examples and Scenarios Mentioned

• Brightspace web page: a typical web client request to Brightspace’s web server, illustrating client-server interaction.

• Authentication flow: logging in triggers credential checks, MFA, and other security steps, showing how security layers integrate with architecture beyond the basic client-server model.

• Gmail/Outlook flows: client to web server and the need to fetch mail from a separate mail service, illustrating cross-service interactions and multi-tiered design.

• General reminder: modern web services often involve a web client, a web server, authentication services, data services (e.g., mail servers), and possibly cloud-based backends.

Connections to Foundational Principles and Real-World Relevance

• Boundary vs environment: understanding where the system ends and the environment begins helps define interfaces and interaction points, which is critical for design, security, and integration.

• Modularity and subsystems: recognizing that large systems contain nested subsystems (e.g., CPU, memory) supports the concept of encapsulation and separation of concerns.

• Layering and interactions: client-server and multi-tier architectures illustrate how responsibilities are separated across layers to improve scalability, maintainability, and flexibility.

• Evolution from local to distributed to cloud: the progression highlights architectural trade-offs between client load, latency, control, and cost.

Ethical, Philosophical, and Practical Implications

• P2P and piracy discussions: P2P networks enable sharing among equals, which has practical benefits (distribution, resilience) but ethical and legal implications when used for pirated content.

• Centralization vs. decentralization: cloud computing centralizes trust and control on the provider side, raising privacy and dependency considerations, while P2P distributes load and data but can raise security and trust concerns.

• Privacy and security: multi-tier and MFA add security layers but also complexity; security design must account for cross-service interactions and potential single points of failure.

• Scalability and load balancing: real-world systems rely on distributing work across multiple entities to avoid overloading any single component, a principle evident in the discussion of CDNs and multi-entity flows.

Quick Takeaways

• A system is a boundary-defined collection of components that work together to accomplish a task; boundaries separate the system from its environment.

• Subsystems are common (e.g., CPU has decoders/executors; memory has cells for data and management).

• System architecture combines the components, how they interact, their constraints, and their environmental interactions to define behavior.

• In distributed systems, client-server is dominant, with several tiers (two-tier, three-tier, and multi-tier) to support complex services.

• Cloud computing pushes more work to the server side and relies on centralized or distributed cloud resources.

• Peer-to-peer networks distribute roles among peers, enabling scalable and resilient file sharing and content delivery.

• Real-world flows include authentication, MFA, and cross-service data access, illustrating the complexity beyond simple client-server models.