🏗️ Architecture Patterns

Common software architecture patterns and when to use them.

Monolith vs Microservices

Aspect	Monolith	Microservices
Complexity	Low at start	High from day one
Deployment	Single unit	Independent services
Scaling	Scale everything	Scale per service
Team size	< 10 devs	Multiple teams
Best for	MVPs, small teams	Large orgs, diverse scaling needs

Rule of thumb: Start monolith, extract services when you have clear boundaries.

Layered architecture

Presentation (UI / API)
    ↓
Application (Use cases / Services)
    ↓
Domain (Business logic / Entities)
    ↓
Infrastructure (DB / External APIs / Files)

Dependencies point inward — domain has no external dependencies.

Common patterns

Repository pattern

Abstracts data access behind an interface. Business logic doesn't know about the database.

Service layer

Encapsulates business logic and orchestrates between repositories and external services.

Event-driven

Components communicate via events instead of direct calls. Good for decoupling.

CQRS

Separate read and write models. Useful when read/write patterns differ significantly.

Saga pattern

Manages distributed transactions across microservices using compensating actions.

Decision guide

Situation	Pattern
Simple CRUD app	Monolith + layered
Complex business rules	Domain-driven design
High read/write asymmetry	CQRS
Multiple independent teams	Microservices
Event-heavy system	Event-driven + message queue
Starting a new product	Modular monolith

Anti-patterns

• Distributed monolith — Microservices that are tightly coupled
• Big ball of mud — No clear structure or boundaries
• Golden hammer — Using the same pattern for everything
• Premature optimization — Over-architecting before understanding the problem