🏗️ Software architecture patterns and design for careers

What you’ll learn

1. Architecture Is the Expensive DecisionsDefine architecture as the decisions expensive to change later and explain why sorting decisions by cost of reversal is the core skill.Software architecture is not diagrams or technology choices but the set of design decisions that are costly to reverse once a system is built and running. Because everything is cheap to change early, teams make architectural choices casually, only for them to harden into expensive constraints as the system grows. The senior skill is the foresight to spot expensive-to-reverse decisions and give them deliberate thought while they are still cheap, holding always to the truth that there is no best architecture, only trade-offs.
2. The One Enemy: ComplexityEstablish complexity as the fundamental enemy and coupling and cohesion as the two levers for managing it.Every architectural pattern is fundamentally a technique for managing complexity — arranging a system so a human can reason about one part without understanding the whole. Complexity is fought with two levers: coupling, the degree parts depend on each other (which should be low), and cohesion, how well things within a part belong together (which should be high). The whole design instinct compresses to 'low coupling, high cohesion', and layers, modules, and microservices are all mechanisms to achieve it.
3. The Layered Monolith: The Sane DefaultPresent the layered monolith as the sane default and explain the downward-dependency rule and the monolith's real strengths and limits.A monolith — one application built and deployed as a unit — is the correct default for most systems, and a well-built one is organised into layers (presentation, business, data) with dependencies pointing downward only. Its strengths are simplicity of development, testing, deployment, and fast reliable in-process calls; its weaknesses only bite at large scale, and even then the pain comes from uncontrolled coupling rather than from being a monolith. The honest guidance is to build a modular monolith and add complexity only when a concrete problem demands it.
4. Following a Request Through the SystemTrace a client-server web request through the layers and load balancer, connecting it to separation of concerns and scaling.Almost every web system is built on the client-server request-response cycle, in which client and server are loosely coupled across the network through an agreed API. A request travels from the client through a load balancer to a server's presentation, business, and data layers and back — the same layered flow stretched across a network. The load balancer, which spreads traffic across many identical stateless server copies, is the foundational trick behind scaling to millions of users.
5. Breaking the Monolith: MicroservicesExplain microservices as a response to organisational and scaling pressure and stress that they relocate complexity rather than remove it.Microservices split a system into small, independently deployable services each owning one business capability, letting very large teams work without blocking and letting components scale separately. But they do not eliminate complexity; they move it from inside the code into the network between services, where calls can be slow, fail, and cascade, and where data consistency and distributed debugging become hard. The honest guidance is reluctance: microservices solve real problems a monolith can't, but paying their operational cost before having the problem is a common, expensive mistake.
6. How Services TalkContrast synchronous and asynchronous service communication and the resilience-vs-simplicity trade-off of message queues.Services can communicate synchronously — calling and waiting, which is simple but creates temporal coupling where a downstream failure can cascade — or asynchronously, sending a message to a queue and moving on. Queues decouple sender and receiver in time, so messages wait during outages and traffic spikes are absorbed, buying resilience and scalability. The cost is that asynchronous systems are harder to reason about and debug and add broker infrastructure, so mature systems use each mode where it fits.
7. The Hardest Problem: DataExplain database-per-service, the loss of single-transaction consistency, and the CAP theorem's consistency-vs-availability trade-off.Microservices demand that each service own its database so services stay loosely coupled, but this destroys the easy consistency of a single-database transaction. The CAP theorem states that during an unavoidable network partition a distributed system must favour consistency (every read sees the latest write) or availability (every request gets an answer), never both. This forces real choices — banks favour consistency, social feeds favour availability — and many systems accept eventual consistency, trading 'right now' for 'very soon' to make large distributed systems possible.
8. Choosing Well, and Building a CareerSynthesize the course into the trade-off mindset, the practice of ADRs, and concrete career advice on architectural judgement.The unifying idea is that there is no best architecture, only trade-offs chosen for a specific context: every pattern buys something and charges for it. The mature engineer asks what forces the system is under and which decisions are expensive to reverse, records the reasoning in Architecture Decision Records, and defaults to simplicity, adding complexity only when a concrete force demands it. For careers, senior engineers are valued for this judgement — starting from the forces, never proposing a pattern without naming its cost.

Questions this course answers

Grounded in trusted sources

• Fowler, M., Patterns of Enterprise Application Architecture (Addison-Wesley)
• Fowler, M. & Lewis, J., 'Microservices' (martinfowler.com, 2014)
• Newman, S., Building Microservices (O'Reilly)
• Richards, M. & Ford, N., Fundamentals of Software Architecture (O'Reilly)
• Kleppmann, M., Designing Data-Intensive Applications (O'Reilly)
• Brewer, E., 'CAP Twelve Years Later' (IEEE Computer, 2012)
• Nygard, M., 'Documenting Architecture Decisions' (ADRs)

Every Wunder lesson is built from real, reputable sources — never invented.

Related Science courses