Architecture & Distributed Systems

The high-level structure of a software system

The components, responsibilities, interfaces and constraints that shape how a system works.

A system whose components run on multiple computers

Software in which independent nodes communicate over a network and must handle partial failure and delay.

An application split into logical tiers

An architecture that separates concerns such as presentation, business logic and data access into layers that may deploy separately.

Software organised into responsibility layers

A structure where each layer offers services to the layer above and depends on layers below.

Ports and Adapters architecture

A design that keeps business logic at the centre and connects external systems through explicit ports and adapters.

Architecture with dependencies pointing inward

A family of designs that isolates core business rules from frameworks, interfaces and infrastructure.

Domain-Driven Design

An approach that models software around the language, rules and boundaries of the business domain.

A boundary within which a domain model is consistent

A DDD boundary that defines where terms, rules and models have a specific meaning.

Service-Oriented Architecture

An architecture built from interoperable services with defined contracts, often integrated across an organisation.

Command Query Responsibility Segregation

A pattern that separates operations that change state from those that read it.

Storing state as an ordered sequence of events

A pattern where changes are recorded as immutable events and current state is derived from their history.

A distributed transaction made of local steps

A pattern that coordinates a long-running business process and uses compensating actions when a step fails.

Stopping calls to a failing dependency

A resilience pattern that temporarily blocks repeated requests after failures, allowing recovery and preventing cascades.

Isolating resources to contain failure

A resilience pattern that separates resource pools so overload in one area does not sink the whole system.

Repeating an operation after a transient failure

A resilience pattern that retries safe operations with limits and delay rather than failing immediately.

The same request can be repeated without extra effect

A property that makes retries safer because applying an operation more than once produces the same intended result.

Replicas converge after a delay

A consistency model in which reads may be temporarily stale but all copies are expected to agree eventually.

Reads reflect the latest completed write

A consistency model that presents a single current view of data, usually with coordination and latency trade-offs.

Consistency, Availability and Partition tolerance

The observation that during a network partition a distributed data system must trade off immediate consistency against availability.

A helper process deployed beside an application

A pattern that adds cross-cutting capabilities such as proxying or telemetry without putting them in the main application.

Incrementally replacing a legacy system

A migration pattern that routes capabilities to new components until the old system can be retired safely.

Backends for Frontends

A pattern that gives each user interface a backend tailored to its data and interaction needs.

Combining data from multiple services

A pattern in which one component calls several services and assembles a response for a client.

Two ways to coordinate distributed work

Choreography lets services react to events independently; orchestration uses a coordinator to direct the sequence.