Software architecture reading path: from patterns to resilient systems at scale
This curriculum takes experienced developers from solid design principles through architectural patterns, trade-off reasoning, and finally the hard problems of distributed and large-scale systems. Each stage builds the vocabulary and mental models needed for the next, so that by the end the reader can confidently make and defend architectural decisions at any scale.
Design Principles & Clean Structure
IntermediateInternalize the core principles (SOLID, coupling, cohesion, layering) that underpin every architectural decision, and learn to express them in clean, maintainable code structures.
▸ Study plan for this stage
Pace: 8–10 weeks, ~40–50 pages/day. Start with "Clean Architecture" (4–5 weeks, ~40 pages/day), then "A Philosophy of Software Design" (3–4 weeks, ~50 pages/day). Allocate 1–2 weeks for review and integration exercises.
- SOLID principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) as foundational rules for flexible, maintainable code
- Coupling and cohesion: how to minimize dependencies between modules and maximize internal coherence to reduce brittleness
- Layered architecture and the Dependency Rule: organizing code into concentric circles where dependencies point inward, isolating business logic from frameworks
- Abstraction and module boundaries: designing interfaces and classes that hide complexity and reduce the surface area of change
- The cost of design decisions: recognizing that architectural choices have long-term consequences, and learning to defer decisions or make them reversible
- Red flags in design: identifying symptoms of poor architecture (deep module interfaces, high cognitive load, tight coupling) before they become crises
- Practical refactoring: applying principles to real code by breaking dependencies, extracting abstractions, and restructuring modules
- What is the Single Responsibility Principle, and why does violating it make code harder to change? Give a concrete example of a class that violates it and how you would refactor it.
- Explain the Dependency Rule in layered architecture. Why should outer layers depend on inner layers, and what breaks when this is inverted?
- What is the difference between coupling and cohesion, and how do they relate to module design? How would you measure or recognize high coupling in a codebase?
- Describe the Interface Segregation Principle. How does forcing a client to depend on methods it doesn't use create problems, and how would you fix it?
- What does Ousterhout mean by 'shallow modules' versus 'deep modules,' and why are deep modules preferable? Give an example of each.
- How do you recognize when a design decision is reversible versus irreversible? What strategies can you use to keep options open early in a project?
- Refactor a tightly coupled class or module from your own codebase (or a provided example) to satisfy the Single Responsibility Principle. Document the before/after structure and explain what became easier to test and modify.
- Design a layered architecture for a small application (e.g., a to-do app, user management system) with clear Entity, Use Case, Interface Adapter, and Framework layers. Draw the dependency diagram and verify that all dependencies point inward.
- Take a concrete example of a 'god class' or 'god function' and break it into smaller, cohesive modules. Measure the reduction in coupling by counting cross-module dependencies before and after.
- Identify an interface in your codebase that violates the Interface Segregation Principle (clients depend on methods they don't use). Split it into smaller, role-based interfaces and refactor the clients.
- Write a short design document for a feature you're building, explicitly listing the architectural decisions you're making and marking each as reversible or irreversible. Justify why irreversible decisions are necessary.
- Read a chapter from 'Clean Architecture' or 'A Philosophy of Software Design' and apply its principles to a real pull request or code review. Write a 1–2 page analysis of what the code does well and what could be improved.
Next up: This stage equips you with the vocabulary and mental models to evaluate and critique architecture; the next stage will teach you how to apply these principles at larger scales—across systems, services, and teams—and how to navigate trade-offs when principles conflict.
Establishes the foundational vocabulary — boundaries, dependencies, layers, and the Dependency Rule — that every subsequent book assumes you know. Start here to build the conceptual skeleton.
Complements Martin by focusing on complexity management and deep vs. shallow modules, sharpening your intuition for what makes a design truly simple before you scale it up.
Patterns & Building Blocks
IntermediateMaster the canonical architectural and design patterns — from classic GoF patterns to enterprise integration blueprints — so you have a rich pattern language to apply and communicate with.
▸ Study plan for this stage
Pace: 12–14 weeks, ~40–50 pages/day. Design Patterns (4–5 weeks), Patterns of Enterprise Application Architecture (4–5 weeks), Enterprise Integration Patterns (3–4 weeks).
- Gang of Four (GoF) design patterns: Creational, Structural, and Behavioral patterns as reusable solutions to common object-oriented design problems
- Pattern structure and vocabulary: Intent, Motivation, Applicability, Participants, Consequences, and Implementation details for communicating design decisions
- Enterprise application architecture patterns: Layering, Domain Model, Data Mapper, Active Record, and Repository patterns for organizing business logic and data access
- Transaction scripts, domain-driven design foundations, and the trade-offs between anemic vs. rich domain models in enterprise systems
- Enterprise Integration Patterns (EIP): Message-oriented architecture, routing, transformation, and endpoint patterns for connecting distributed systems
- Asynchronous messaging, event-driven architecture, and choreography vs. orchestration for building loosely coupled, scalable systems
- Pattern selection and composition: Knowing when and how to combine patterns to solve real-world architectural challenges without over-engineering
- What are the three categories of GoF patterns (Creational, Structural, Behavioral), and can you identify which pattern solves a given design problem and explain its trade-offs?
- How do the Domain Model, Active Record, and Data Mapper patterns differ in organizing business logic and persistence, and when is each appropriate?
- What is the Repository pattern, and how does it abstract data access to support testability and domain-driven design?
- Describe the core message-oriented patterns in Enterprise Integration Patterns: how do Message Router, Content-Based Router, and Message Transformer solve integration challenges?
- What are the differences between synchronous request-reply and asynchronous messaging, and when should you choose each for enterprise integration?
- How do Saga and Process Manager patterns handle distributed transactions and long-running business processes across multiple systems?
- Implement 5–6 GoF patterns (e.g., Singleton, Factory, Observer, Strategy, Decorator, Adapter) in your primary language; document Intent and Consequences for each.
- Refactor a monolithic transaction script into a layered architecture using Domain Model and Repository patterns; compare code clarity and testability.
- Design a small e-commerce domain model (Orders, Products, Customers) using rich domain objects; identify where Active Record vs. Data Mapper would apply.
- Map out a multi-system integration scenario (e.g., order processing across inventory, payment, and shipping systems) using Enterprise Integration Patterns; sketch message flows with routers, transformers, and endpoints.
- Build a simple message-driven system using a message broker (e.g., RabbitMQ, Kafka) that demonstrates Message Router, Content-Based Router, and Dead Letter Channel patterns.
- Document a pattern decision log for a real or hypothetical project: for each major design decision, record which pattern(s) you chose, why, and what trade-offs you accepted.
Next up: This stage equips you with a shared vocabulary and proven solutions for common architectural problems; the next stage will teach you how to apply these patterns at system scale, orchestrating them into coherent architectures that balance competing concerns like scalability, resilience, and maintainability.
The GoF catalog is the shared language of software structure; reading it now gives you the precise pattern names and intent that architecture books reference constantly.
Bridges object-level patterns to system-level concerns (persistence, concurrency, session state), directly preparing you for service and distributed architecture discussions.
Introduces the messaging and integration patterns (channels, routers, transformers) that are the backbone of modern service-oriented and event-driven architectures.
Software Architecture in Practice
IntermediateLearn how to make, document, evaluate, and communicate architectural decisions as a deliberate engineering discipline, including quality attributes and architectural trade-off analysis.
▸ Study plan for this stage
Pace: 8–10 weeks, ~40–50 pages/day (mix of reading and active note-taking)
- Architectural thinking: shifting from code-level to system-level decision-making and understanding trade-offs across multiple dimensions
- Quality attributes (performance, scalability, availability, security, maintainability) as explicit constraints that drive architectural decisions
- Architectural Decision Records (ADRs) and documentation as critical tools for capturing rationale, alternatives considered, and consequences
- The four dimensions of architecture: structure, communication, decision-making, and governance
- Architectural styles and patterns (layered, event-driven, microservices, modular monoliths) as solution templates with inherent trade-offs
- Evaluating trade-offs systematically: cost, complexity, team capability, deployment, scalability, and maintainability implications
- Communicating architecture effectively to different stakeholders (executives, developers, operations) with appropriate detail and language
- Incremental architecture: evolving systems deliberately rather than designing everything upfront, with continuous evaluation and adjustment
- What is the difference between architectural thinking and programming thinking, and why does this shift matter for system design?
- How do quality attributes (like performance, scalability, and security) influence architectural decisions, and how do you prioritize conflicting quality attribute requirements?
- What is an Architectural Decision Record (ADR), and why is documenting the rationale and alternatives considered more valuable than documenting the decision itself?
- Given a specific business problem, how would you evaluate trade-offs between different architectural styles (e.g., monolith vs. microservices) across dimensions like team size, deployment complexity, and operational overhead?
- How do you communicate architectural decisions to different audiences (C-suite, development teams, operations), and what level of detail is appropriate for each?
- What is the relationship between architectural governance, decision-making authority, and team autonomy, and how do you balance standardization with flexibility?
- Read and annotate Part I of 'Fundamentals' (Chapters 1–4) on architectural thinking and foundations. Summarize in your own words why architecture matters and how it differs from design.
- Document a real architectural decision from your current or past project as an ADR, including context, alternatives considered, decision, and consequences. If you lack a project, create a hypothetical ADR for a system described in the books.
- Create a quality attribute matrix for a system of your choice (e.g., a web application, mobile app, or system from the books). List 5–7 quality attributes, rate their importance (1–5), and explain how each would influence architectural choices.
- Compare two architectural styles (e.g., layered vs. event-driven, or monolith vs. microservices) by building a trade-off analysis table covering: team structure, deployment complexity, scalability, testability, operational overhead, and time-to-market. Use examples from the books.
- Design a simple system architecture (e.g., an e-commerce platform or content management system) and write a one-page architecture overview document for three different audiences: a CTO, a developer team, and an operations team. Vary language and detail appropriately.
- Work through a case study from 'Software Architecture: The Hard Parts' (e.g., a migration or decomposition scenario) and write a reflection on the trade-offs made, what you would do differently, and why.
Next up: This stage equips you with the vocabulary, frameworks, and decision-making discipline to evaluate and justify architectural choices systematically; the next stage will likely deepen your ability to design and implement specific architectural patterns at scale, or to specialize in a particular domain (microservices, distributed systems, event-driven architecture) with confidence grounded in this fo
Provides a structured framework for architectural styles (layered, event-driven, microservices, etc.) and the soft skills of the architect role — the ideal bridge from patterns to practice.
Focuses entirely on trade-off analysis and decomposition decisions, teaching you how to reason through the genuinely difficult choices that have no single right answer.
Distributed Systems & Scalability
ExpertDeeply understand the theoretical and practical challenges of distributed systems — consistency, replication, consensus, and failure — and how real large-scale systems are designed around them.
▸ Study plan for this stage
Pace: 8–10 weeks, ~40–50 pages/day (alternating between deep concept chapters and practical architecture chapters)
- Consistency models (strong, eventual, causal) and their trade-offs in distributed systems
- Replication strategies (leader-based, leaderless, multi-leader) and their failure modes
- Consensus algorithms (Raft, Paxos, Byzantine fault tolerance) and when to use them
- Partitioning and sharding strategies to handle data at scale and manage failure domains
- Microservice boundaries and decomposition: how to split systems to enable independent scaling and deployment
- Failure detection, recovery, and resilience patterns in distributed architectures
- Operational complexity: monitoring, debugging, and managing distributed systems in production
- Network unreliability and its implications for system design (timeouts, retries, idempotency)
- What are the key differences between strong consistency, eventual consistency, and causal consistency, and when would you choose each for a real system?
- Explain the CAP theorem and describe how real systems (e.g., databases, caches) navigate its constraints.
- How do leader-based and leaderless replication differ in their failure handling and consistency guarantees?
- What problem does consensus solve, and why is it difficult to achieve in asynchronous networks? Describe how Raft addresses this.
- How should you partition data across multiple nodes, and what are the operational consequences of different partitioning strategies?
- What defines a microservice boundary, and how do you decide whether to split or merge services based on scalability and failure isolation?
- Describe the cascading failure problem and at least three patterns (e.g., timeouts, circuit breakers, bulkheads) to prevent it.
- How do you handle idempotency and exactly-once semantics in a system where network failures are inevitable?
- Read Part I of 'Designing Data-Intensive Applications' (Foundations) and create a comparison table of consistency models with real-world examples (SQL databases, NoSQL stores, caches) from your experience.
- Implement a simple leader-follower replication system in your language of choice (e.g., a key-value store with a primary and replica), then deliberately introduce network partitions and observe failure modes.
- Study the Raft consensus algorithm (Chapter 9 of DDIA) and simulate a 5-node Raft cluster using an existing library (e.g., etcd, Consul) or a visualization tool; document what happens during leader failure.
- Design a data partitioning strategy for a hypothetical e-commerce system (users, orders, products) across 10 nodes; identify hot spots and rebalancing challenges.
- Read 'Building Microservices' chapters on service boundaries and decomposition; refactor a monolithic application (real or hypothetical) into 4–6 services, documenting your boundary decisions.
- Implement a resilience pattern (circuit breaker, timeout, retry with exponential backoff) in a client that calls an unreliable downstream service; test it under failure conditions.
- Trace a distributed transaction across 3+ services (e.g., order → payment → inventory) and identify where consistency breaks; propose a saga or event-driven solution.
- Set up monitoring and alerting for a multi-service system (using tools like Prometheus, Jaeger, or similar); practice identifying cascading failures from logs and metrics.
Next up: This stage equips you with the foundational theory and practical patterns for building systems that scale and survive failure; the next stage will focus on applying these principles to specific domains (e.g., real-time systems, event streaming, or operational excellence) and deepening your expertise in one or more specialized areas.
The single most comprehensive treatment of data systems, consistency models, replication, and stream processing; essential reading before tackling any distributed architecture.
Translates distributed systems theory into concrete microservice design decisions — decomposition, communication, resilience, and deployment — completing the practical picture.
Discussion
Keep reading
Paths that share books, cover the same subject, or open a related topic.
