Course Introduction

Three teams build the same online store.

Each store lets customers browse products, pay by card and track their orders.

All three teams write clean, tested code, and all three stores work well on an ordinary day.

Then a holiday sale begins, traffic jumps, and the payment provider stops answering for ten minutes. The three stores behave very differently.

The first team built one backend application that runs in one process and uses one database. To handle the sale, it runs more copies of the whole application, even though only checkout is busy. When the payment provider stops answering, checkout requests wait for it. Because they share the process with everything else, the whole store can slow down.

The second team split the backend into separate services for the catalog, orders and payments, each with its own database. It adds capacity only to the busy services, and the payment outage is easier to contain inside the payment service. The cost appears elsewhere. A feature that touches orders and payments now needs two releases in the right order, and some failures now happen in the network between services.

The third team made checkout publish a message, "order placed", and let payment and shipping react to it on their own schedule. During the outage, customers can still place orders, and the payment requests wait in a queue until the provider recovers. The cost is that a customer may learn several minutes later that the card was declined. Following one order through the system also takes more effort.

None of these teams wrote worse code than the others. They made different decisions about structure: the parts a system has, the job of each part, how the parts communicate, and which choices will be expensive to change later. Those decisions, not the code inside any one function, set what each store does well and where it struggles. This course teaches you to see such decisions, compare them and make them on purpose.

Why Architecture Styles Matter

An architecture decision is a design decision that touches many parts or teams, takes weeks or more to change in production, and is hard to undo. Each team above made several, such as one process or many services, and direct calls or messages. Choosing the name of a function is not an architecture decision, because an editor can rename it in seconds.

An architecture style is a named, reusable set of architecture decisions with known trade-offs. A trade-off is a choice in which improving one property of a system makes another property worse. The three teams used three styles: a monolith, microservices and event-driven architecture. The word "monolith" alone states several decisions. The backend is one deployable artifact (a single packaged build shipped as a unit), it runs in one process, and it uses one database. An engineer who knows the style can predict much of the sale-day behavior described above before reading any code.

Most engineers do not choose a style on an empty page. They join a system whose style was chosen years earlier, often by people who have since left. Knowing the styles helps in both situations. You can recognize the decisions already built into the system you maintain, and see why some changes take an hour while others take a month. You can also propose a change in terms the rest of the team understands and can check: what it improves, what it costs, and whether the team can afford the difference.

Who This Course Is For

This course is written for junior and mid-level software engineers who build and maintain backend systems. You may already write features with confidence. Now you want to take part in structural decisions and explain the reasons behind them.

The course assumes that you already know three things.

• One programming language. The code examples are written in Python, and you can switch most of them to Java, JavaScript, C# or Go.
• HTTP. You should know what a request, a response and a status code are.
• A relational database. You should be able to read a SQL query and know what a table and a transaction are.

You do not need prior experience with distributed systems, message brokers, a particular cloud provider or a particular framework. Every term beyond the three items above is defined in the lesson where it first appears.

How the Course Is Organized

The course has four chapters. The first builds a shared vocabulary for judging any design. The second applies that vocabulary to each style in turn. The third teaches you to make, record and review architecture decisions on a running system, and ends with three capstone projects. The fourth holds two final assessments that cover the whole course.

Architecture Fundamentals has five lessons after this one. All five use the same running example, a food-delivery app with customer, restaurant and courier apps that call one backend. The lessons return to that app and change one part of it at a time, so each idea builds on the one before it.

1. What Software Architecture Is defines architecture, separates architecture decisions from detailed design with three questions, and introduces architecture styles.
2. Responsibilities and Boundaries shows how to give each part of a system one clear job. It also shows how boundaries and interfaces hide what a part does inside.
3. Coupling, Cohesion, and Dependencies explains how a change in one part forces changes in others. It also covers how to keep related code together and which way dependencies should point.
4. Quality Attributes defines quality attributes, which are measurable properties of how well a system does its job. It covers the five that the style lessons use to judge every style (changeability, performance, availability, security and cost) and how to measure each one.
5. Constraints and Trade-offs shows how to score options in a weighted table. It then shows how to check the winner against the team's constraints, which are limits set outside the team, such as a budget or a deadline. It also shows how to record the result in an architecture decision record (ADR), a short document that states one decision, its context and its consequences.

Architecture Styles has fifteen lessons, one for each style. The table below lists them in course order, each with its core idea.

The fifteen lessons fall into four groups. Lessons 1 to 4 cover the basic structures of one application, and lessons 5 to 7 split a system into services that communicate through calls or events. Lessons 8 to 11 organize code and processing, and lessons 12 to 15 address distribution and scale.

The diagram below shows the first two chapters, the four groups of style lessons and the recommended path through them.