Skip to content

3.0 Introduction to Part 3: Systems

Architecture is the set of decisions that are expensive to reverse. How do you split a system into parts? How do those parts talk to each other? How is the data modeled? And how does the whole thing behave under load and under failure? Part 3 is about making those calls on purpose. On a small team, architecture can live in a few heads and evolve as you go. In a large organization (hundreds of engineers, dozens of teams, systems that will outlive the careers of the people who build them), architecture becomes the thing that keeps everyone coordinated. When it is clear, teams move independently without colliding. When it is vague, every cross-team dependency turns into a negotiation, and every incident turns into an archaeology project.

The stakes are highest in enterprise and government. A tax engine, a benefits platform, a national health record, or a bank's core ledger is long-lived, heavily regulated, shared across departments, and answerable to the public. The decisions you make today about coupling, data ownership, and quality attributes will constrain what is possible for a decade or more. Regulators and auditors increasingly expect documented, defensible architecture, with real evidence that reliability, security, privacy, and durability were designed in, not bolted on afterward. The failures that make headlines are architectural failures: portals that buckle on launch day, filing systems that time out at the deadline, migrations that lose or double-count records.

This part starts with the durable fundamentals, moves through concrete structural choices, then into the realities of distribution, data, and scale, and finishes with the hardest problem most large organizations actually face: modernizing the systems they already run. The thread that ties it together: good architecture is a series of conscious trade-offs, not a fashionable default.

Chapters in this part

  • 3.1 Architecture fundamentals. The durable tools that survive technology fashion: quality attributes (the "-ilities"), architecturally significant requirements, fitness functions (automated tests that guard a chosen architectural quality) and evolutionary architecture, lightweight documentation with the C4 model (nested architecture diagrams at four zoom levels) and arc42 (an architecture documentation template), and structured trade-off analysis.
  • 3.2 Architectural styles and patterns. A survey of the major system shapes, from monolith through microservices, event-driven architectures with CQRS (Command Query Responsibility Segregation, which separates the read models from the write models) and event sourcing (storing state as an append-only log of events), service mesh (a dedicated infrastructure layer for service-to-service communication) and gateways, serverless, and hexagonal and clean architecture, with guidance on when each fits, framed by Conway's Law (systems tend to mirror the communication structure of the organization that builds them).
  • 3.3 Distributed systems. The hard truths that appear the moment you cross a network boundary (unreliable networks, partial failure, no shared clock), and the standard defenses: consistency reasoning, idempotency (making an operation safe to repeat), retries with backoff, circuit breakers (which stop calling a failing dependency), sagas (sequences of local transactions with compensating undo steps), and distributed observability.
  • 3.4 Data architecture and storage. How data is modeled, stored, kept consistent, and served fast at scale: the major storage paradigms and when to use each, polyglot persistence (using several specialized data stores in one system), schema evolution and migration, caching and CDNs (content delivery networks), and transactions and concurrency under load.
  • 3.5 Scalability, performance, and resilience. Three distinct qualities designed in rather than retrofitted: horizontal and vertical scaling, statelessness and sharding (splitting data across machines by a key), load balancing and autoscaling, performance budgets, resilience patterns and chaos engineering, and multi-region disaster recovery framed by RTO (recovery time objective) and RPO (recovery point objective).
  • 3.6 Legacy modernization. The incremental patterns that actually work, strangler fig (growing a new system around the old one until the old one can be retired) and branch-by-abstraction (replacing a component behind an interface on the main line of development), plus legacy risk assessment, mainframe and COBOL (Common Business-Oriented Language) stewardship, data migration and dual-running, and how to resist the big-rewrite temptation that produces the field's most expensive failures.
  • 3.7 Software maintenance. The dominant phase of the software lifetime: corrective, adaptive, perfective, and preventive maintenance, program comprehension and reengineering, and designing for maintainability so long-lived systems stay affordable to change.
  • 3.8 Interoperability and open standards. Designing systems to interoperate through open standards rather than bespoke integrations: technical, syntactic, and semantic interoperability, domain standards such as FHIR in healthcare, and the cost of proprietary lock-in.
  • 3.9 Systems engineering. Engineering complex systems end to end, often combining software, hardware, people, and processes: lifecycle, requirements allocation and traceability, interfaces, integration, and verification and validation.
  • 3.10 Embedded and real-time systems. Software for devices under tight constraints: real-time behavior and determinism, an RTOS or bare-metal firmware, limited memory and power, hardware interaction, and safety-critical standards.

How these chapters interrelate

The chapters build on one another in order. Chapter 3.1 gives you the vocabulary (quality attributes and trade-off analysis) that every later chapter uses; the "-ilities" it names are exactly what chapters 3.4 and 3.5 make concrete. Chapter 3.2 turns those fundamentals into structural choices, and the more distributed styles it endorses (microservices, event-driven, service mesh) bring the costs that chapter 3.3 teaches you to manage. Chapters 3.3, 3.4, and 3.5 lean heavily on one another: distribution forces the consistency and durability decisions of data architecture, and together distribution and data shape what scalability and resilience you can actually reach. Chapter 3.6 closes the loop, because most large organizations are not building on a blank page: they are evolving systems of record that constrain every choice the earlier chapters describe.

Part 3 also reaches outward. Chapter 3.2 draws on the design principles and Domain-Driven Design of chapter 2.2 to find good service boundaries. The operational disciplines that keep these systems running live in Part 9: site reliability engineering (chapter 9.1) and observability (chapter 9.2) are where architectural resilience is proven in production. The security and privacy properties regulators demand are designed here but detailed in Part 4, and the platform and delivery practices in Part 8 decide whether an architecture can actually be shipped and operated by many teams at once.