Architecture Styles: Patterns, Partitioning, Distributed Fallacies & Team Topologies

1. Architecture Style ≠ Architecture Pattern

Architecture style describes the distinct characteristics of an architecture, including:

Component topology – defines how components and their dependencies are organized.

Physical architecture – determines whether the system is monolithic or distributed.

Deployment – granularity and deployment frequency relate to the style.

Communication style – monoliths use in-process calls; distributed systems use network protocols.

Data topology – data organization is also dictated by the architecture style.

Architecture pattern is a more concrete implementation template, a reusable solution for a specific class of problems.

2. Three Primitive Patterns

Before modern styles, three foundational patterns exist:

Big Ball of Mud – no structure, everything tightly coupled; changes cause unpredictable ripple effects, developers spend time debugging instead of building features.

Unitary Architecture – earliest form, software and hardware as a single entity on mainframes; later data separated, then networks enabled distributed systems. Today only in embedded or highly constrained environments.

Client/Server Architecture – basic distributed architecture separating front-end and back-end into two layers; established the mindset of separating modules by technical concern.

3. Technical Partitioning vs Domain Partitioning

How should top-level components be divided? Two approaches:

Technical partitioning – by technical capability: presentation, business logic, services, persistence. Pros: developers easily find their layer; custom and generic code separate. Cons: a business workflow spans all layers, so a change touches nearly every layer.

Domain partitioning – by business domain or workflow: order, inventory, payment, notification. Each top-level component contains its own presentation, logic, data sub-structures. Pros: aligns with business operations; matches Domain-Driven Design (DDD); enables cross-functional teams per domain. Cons: custom code may be duplicated across domain components.

No absolute right or wrong, but industry trend favors domain partitioning for both monolithic and distributed architectures.

4. Monolithic vs Distributed

Two major style categories. Many assume distributed is superior due to microservices hype, but you must understand the Fallacies of Distributed Computing (Deutsch, 1994):

The network is reliable – packet loss, disconnects, timeouts happen; need retries, circuit breakers, fault tolerance.

Latency is zero – local calls are nanoseconds/microseconds; remote calls are milliseconds; accumulated latency slows systems.

Bandwidth is infinite – network bandwidth has limits; large payloads saturate it; must control data volume.

The network is secure – every endpoint needs protection; attack surface grows orders of magnitude; encryption/auth adds performance overhead.

Topology never changes – service instances scale dynamically; hard-coded addresses fail; service discovery required.

There is only one administrator – multiple teams, environments; unified governance and monitoring needed.

Transport cost is zero – serialization, transmission, deserialization have real cost per call.

The network is homogeneous – different languages, protocols; need multi-stack communication adapters.

Three later additions:

Versioning is easy

Compensating updates always work

Observability is optional

5. Team Topology and Architecture

Conway's Law (1960s): organizations design systems that mirror their communication structures. Example: teams split by technical role (front-end, back-end, DBA) – each owns a layer, no one owns the full workflow. Changing an order flow requires coordination across three teams, taking days.

Inverse Conway Maneuver (Jonny Leroy, Thoughtworks): evolve team structure and architecture together so organization drives desired architecture. This led to the book Team Topologies , the leading framework for team topology discussions.

Team Topologies defines four team types:

Stream-aligned Teams – core delivery force; focus on a single workflow end-to-end; minimize external dependencies.

Enabling Teams – do not deliver features directly; fill capability gaps, provide expertise and best practices to stream-aligned teams.

Complicated-subsystem Teams – handle highly specialized subsystems (video codecs, 3D rendering, HPC) with high cognitive load; expose as services so stream-aligned teams don't need deep expertise.

Platform Teams – build internal products (self-service APIs, tools, services, knowledge bases) to accelerate stream-aligned teams without exposing platform internals.

6. Summary

Clarify concepts first : style is the blueprint; pattern is the construction plan.

Understand partitioning logic : technical and domain partitioning each have trade-offs, but domain partitioning is becoming mainstream.

Recognize the cost : distributed is not free; it demands real engineering investment.

Align teams last : ivory-tower architecture fails; team topology and architecture must be consistent. 1. Fundamentals of Software Architecture 2nd Chapter 9↩︎