# System Patterns

System patterns define the **top-level structural blueprint** of an application — how processes are split, how they communicate, and where boundaries live. This is the first decision you make before writing any code, and the one that is hardest to change later.

I learned this the hard way: I built a full microservices stack for a two-person team project. The overhead of service discovery, distributed tracing, and inter-service contracts nearly killed the project before we shipped anything useful. Choosing the right system pattern up front would have saved months.

## Patterns in This Section

| Pattern                                                                                                                                            | When I Reach For It                                          | Article                                                                                                                                                                                          |
| -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [Monolithic](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns)             | Starting a new project, single team, unknown domain          | [01-monolithic-architecture.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns/01-monolithic-architecture)             |
| [N-Tier](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns)                 | Web apps with clear presentation/business/data separation    | [02-n-tier-architecture.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns/02-n-tier-architecture)                     |
| [Service-Oriented (SOA)](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns) | Enterprise integration across teams or systems               | [03-service-oriented-architecture.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns/03-service-oriented-architecture) |
| [Microservice](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns)           | Independent scaling, polyglot teams, domain boundaries clear | [04-microservice-architecture.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns/04-microservice-architecture)         |
| [Serverless](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns)             | Event-triggered workloads, variable traffic, cost efficiency | [05-serverless-architecture.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns/05-serverless-architecture)             |
| [Distributed Systems](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns)    | Multi-node coordination, consistency across boundaries       | [06-distributed-systems.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns/06-distributed-systems)                     |
| [Peer-to-Peer](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns)           | Decentralised communication, no central authority            | [07-peer-to-peer-architecture.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/system-patterns/07-peer-to-peer-architecture)         |

## How to Read These Articles

Each article follows the same structure:

1. **The problem it solves** — a real situation from my projects that led me to the pattern
2. **Core concepts** — what defines the pattern and the tradeoffs
3. **When to use / when not to** — honest guidance based on experience
4. **Code or structure examples** — practical illustrations, not textbook abstractions
5. **What I would do differently** — retrospective notes

## Relationship to Application Patterns

System patterns answer: *"How many processes are there, and how do they interact?"*

Application patterns answer: *"How is the code inside each process organised?"*

You can combine them freely: a microservice system can use onion architecture inside each service. A monolith can use CQRS internally. See [Application Patterns](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns) for those choices.