CMPE273 · Module 1

Introduction to Enterprise Distributed Systems

Define distributed systems, contrast them with parallel systems, and examine why enterprise systems become difficult once communication crosses network boundaries.

Learning Objectives

  1. Explain what makes a system distributed and how it differs from a parallel system.
  2. Describe core distributed systems goals including scalability, availability, reliability, transparency, and fault tolerance.
  3. Identify partial failure, latency, coordination, and network uncertainty as central sources of design difficulty.
  4. Recognize distributed systems patterns in cloud platforms, microservices, financial systems, streaming systems, and agentic systems.

Core Concepts

Distributed System

A set of independent computers that coordinate over a network and appear to users or applications as one coherent system.

Parallel System

A system focused on dividing computation across processors, usually with tighter control over communication, memory, and execution.

Scalability

The ability to handle growth in users, requests, data volume, or geographic reach without redesigning the entire system.

Availability

The ability of a system to remain usable when components fail, traffic spikes, or dependencies become degraded.

Fault Tolerance

The ability to continue operating correctly, possibly in a reduced mode, despite hardware, software, or network failures.

Partial Failure

A failure mode where one part of the system fails or becomes unreachable while other parts continue running.

Diagrams

Single-Node Failure Versus Partial Failure

flowchart LR
  subgraph singleNode[Single node]
    c1[Client] --> app[Application and data]
    app -.-> down[Whole system unavailable]
  end
  subgraph distributedSystem[Distributed system]
    c2[Client] --> gw[API Gateway]
    gw --> svcA[Service A healthy]
    gw --> svcB[Service B unavailable]
    svcA --> db[Shared data store]
    svcB -.-> db
  end

The left side shows a single-node application where one server failure stops the whole system. The right side shows a distributed application where Service B is unavailable while clients, the gateway, Service A, and the database may still be running. The system is neither fully healthy nor fully down.

Lost Response After Successful Processing

sequenceDiagram
  participant B as Service B
  participant N as Network
  participant A as Service A
  participant D as Data Store
  B->>N: createOrder(requestId=42)
  N->>A: deliver request
  A->>D: commit order 42
  D-->>A: commit ok
  A-->>N: response ok
  Note over N: response is lost
  N-->>B: no response
  B->>B: timeout, outcome unknown

Service B sends a create request to Service A. Service A commits the operation, but the response is lost on the network. Service B only observes a timeout, so it cannot know whether the operation happened without an idempotency key, status lookup, or reconciliation flow.

Inconsistent State Across Two Services

flowchart LR
  orders[Order service state paid]
  shipping[Shipping service state pending]
  event[Payment authorized event delayed]
  orders --> event
  event -.-> shipping
  orders -.-> userA[Customer support view paid]
  shipping -.-> userB[Fulfillment view pending]

The order service has recorded an order as paid, while the shipping service still sees it as pending because the payment event has not arrived or has not been processed. The diagram is understandable by reading the state labels, not by relying on color.

Distributed Request Path With Logs, Metrics, and Traces

flowchart LR
  client[Client] --> gateway[API Gateway]
  gateway --> svcA[Service A]
  svcA --> broker[Message Broker]
  broker --> svcB[Service B]
  svcB --> db[Database]
  gateway -.-> obs[Observability platform]
  svcA -.-> obs
  broker -.-> obs
  svcB -.-> obs
  db -.-> obs

A request moves from client to gateway to services and data stores. Each component emits telemetry. Traces connect the path, logs explain local decisions, and metrics show aggregate health.

Enterprise Distributed Systems Stack

flowchart TB
  clients[Users clients partner systems]
  edge[Edge DNS CDN load balancer API gateway]
  services[Services domain APIs workflows AI agents]
  events[Events broker streams queues]
  data[Data relational document cache search lake]
  platform[Platform containers orchestration cloud regions]
  observe[Operations logs metrics traces alerts]
  govern[Governance security policy compliance cost]
  clients --> edge --> services
  services --> events
  services --> data
  events --> data
  platform --> services
  services --> observe
  platform --> observe
  govern -.-> edge
  govern -.-> services
  govern -.-> data

The stack moves from users and clients through edge routing, services, events, data, platform infrastructure, observability, and governance. Each layer introduces responsibilities that must be designed and operated explicitly.

Week 1 Service A and Service B Lab Architecture

flowchart LR
  student[Student browser or curl]
  serviceB[Service B caller]
  serviceA[Service A worker]
  store[Service A local store]
  logs[Console logs with request IDs]
  student --> serviceB
  serviceB --> serviceA
  serviceA --> store
  serviceB -.-> logs
  serviceA -.-> logs
  serviceA -.-> serviceB

Service B calls Service A over HTTP and includes a request ID. Service A records work in its local store and both services emit logs. The lab varies response delay and dropped responses so students can see how uncertainty appears at Service B.

Key Takeaways

Lab Links