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
Enterprise integration across teams or systems
Independent scaling, polyglot teams, domain boundaries clear
How to Read These Articles
Each article follows the same structure:
The problem it solves — a real situation from my projects that led me to the pattern
Core concepts — what defines the pattern and the tradeoffs
When to use / when not to — honest guidance based on experience
Code or structure examples — practical illustrations, not textbook abstractions
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 for those choices.
Last updated