Patterns
Overview of software design and architecture patterns—recurring solutions with explicit trade-offs and links into deeper articles.
This section catalogues patterns: named, repeatable approaches to recurring design problems. Patterns are not mandates. Each entry should clarify the problem, the structure of the solution, consequences, and when not to apply it.
How patterns relate to the rest of the knowledge base
Many articles already describe pattern-shaped ideas under their natural domains:
| Pattern-shaped topic | Where it lives today |
|---|---|
| Modular boundaries | Modular Monolith |
| Ports and adapters | Hexagonal Architecture |
| Domain events / outbox | Event-Driven Architecture |
| Hash ring placement | Consistent Hashing |
| Optimistic / pessimistic concurrency | Pessimistic vs Optimistic Locking |
As this section grows, shorter pattern pages may summarise a technique and link out to full treatments.
Principles for using patterns
- Name the problem first — patterns without pain become cargo cult
- Prefer the smallest mechanism — a single SQL invariant beats a ceremony of locks and sagas
- Preserve evolution paths — modular monoliths and hexagonal ports make later extraction cheaper
- Measure consequences — latency, operability, and team cognitive load are part of the pattern