System Architecture

Tap menu for chapters & tools

Chapter 14

System Architecture

The long-lived structure: domains, runtime, and evolution

20 min read

System architecture is the long-lived shape of the whole: domain boundaries, deploy map, how systems talk, and the rules for change. System design answers how we build this feature path. Architecture answers how the machine stays coherent when people and products keep moving.

Architecture views a lead should maintain

  • Domain view: bounded contexts, ubiquitous language, ownership map.
  • Runtime view: services, data stores, queues, external dependencies.
  • Deployment view: environments, pipelines, regions, blast radius.
  • Data view: sources of truth, retention, lineage, consistency expectations.
  • Security view: trust boundaries, identity, secrets, compliance zones.

Monolith, modular monolith, services: choose with eyes open

There is no universal winner. A modular monolith with hard module boundaries often beats a premature microservice mesh for a small team. Services earn their keep when independent deployability, scaling, or team autonomy clearly outweigh distributed-system cost.

  1. Prefer modularity of design before distribution of deployment.
  2. Split on domain and change frequency, not on folder count.
  3. Pay the tax of distributed tracing, contracts, and on-call only when needed.
  4. Revisit splits quarterly with incident and delivery data, not slogans.

Integration styles and coupling

  • Synchronous request/response: simple, but chains amplify latency and failure.
  • Async events/messages: resilient decoupling, harder end-to-end reasoning.
  • Shared data: fastest short-term, most expensive long-term coupling.
  • Anti-corruption layers at messy boundaries with legacy or vendors.
Architecture fitness functions

Automate a few checks that protect architecture intent: dependency direction tests, contract tests, max service depth, schema compatibility, or bundle size budgets. Architecture that is not enforced drifts.

Lead responsibilities for system architecture

  1. Keep a living architecture page: diagram, owners, SLOs, top risks.
  2. Run a lightweight architecture review for cross-cutting changes.
  3. Fund debt that blocks safety or speed; kill gold-plating rewrites.
  4. Grow architects-in-practice on the team through design rotations.
  5. Align org structure with desired architecture (Conway awareness).

System architecture is a leadership product: it either reduces cognitive load or multiplies it.

Diagrams for this topic

Visual models you can redraw on a whiteboard or in a design review.

Diagram

Monolith → modular → services
  1. 1Modular monolith
  2. 2Clear module APIs
  3. 3Extract high-churn edge
  4. 4Independent deploy only when paid for
  5. 5Fitness functions guard boundaries

Diagram

Data ownership trade-offs

Shared DB

  • Fast start
  • Hidden coupling
  • Schema freezes everyone

Service-owned data

  • Clear contracts
  • Evolution freedom
  • Needs sync patterns

Diagram

Evolution loop
  1. 1Measure fitness
  2. 2Find bottleneck
  3. 3Small reversible change
  4. 4Verify in prod
  5. 5Document decision
  6. Loop: after the last step, return to the first.

Worked examples

Concrete situations: what goes wrong, what to try instead, what changes.

Premature service split

Setting. Two teams share a modular monolith. Deploy friction is high.

Common miss

Split into 15 microservices in one quarter.

Stronger move

Enforce module boundaries, add CI ownership checks, extract the one domain with independent scale and team ownership first.

Outcome. You pay distributed tax only where Conway + scale demand it.

Service split for the org chart meme

Setting. Leadership wants microservices because “scale,” with one team of six.

Common miss

Split the monolith into 12 repos in a quarter.

Stronger move

Modularize first, extract one domain with independent scale needs, and add fitness checks for boundaries.

Outcome. You gain deploy independence without paying full distributed tax yet.

Resources specific to this chapter

Go deeper with books, videos, and tools matched to this topic, not a generic dump.

Practice

End-of-chapter drill

Draw (boxes or bullets) domain view + runtime view for your area. Mark one boundary that is lying today.

Hint: Lying boundary = shared DB, unclear owner, or chatty coupling.

Architecture docs that nobody updates are fiction.

Learn more on this topic

Full resource library