Architecture Cheat Sheet
Architecture is not one pattern choice. These decisions are on different axes and can be combined.
| Decision | Prefer left when | Prefer right when | Main cost of right |
|---|---|---|---|
| Monolith ↔ services | One/few teams, coordinated releases are acceptable, boundaries are still evolving | Parts genuinely need independent ownership, deployment, scaling or technology | Distributed operations, latency and consistency |
| Layers ↔ vertical slices | Technical concerns are uniform and change together | Features should change independently and usually cut through all layers | Duplication and less global uniformity |
| Lightweight ↔ domain-centric | Mostly CRUD, simple rules, short feedback loop | Complex and changing business rules must survive technology changes | Abstractions and boilerplate |
| Synchronous ↔ event-driven | The caller needs an immediate result and the flow should stay simple | Consumers can react later, failures must be isolated or load must be buffered | Eventual consistency and difficult debugging |
| Shared data ↔ isolated data / CQRS | Transactions and simple queries matter more than autonomy | Data ownership or read/write needs differ significantly | Duplication, synchronization and migrations |
| Long-running ↔ serverless | Workload is steady or runtime control matters | Work is event-driven, bursty or should scale to zero | Cold starts, platform constraints and distributed complexity |
Common starting points
| Scenario | Start with |
|---|---|
| Simple CRUD application | Lightweight modular monolith with vertical slices |
| Complex, long-lived business domain | Domain-centric modular monolith; add hexagonal architecture when multiple adapters matter |
| Multiple autonomous teams with independent release cycles | Services split by stable business boundaries |
| Integration-heavy or asynchronous workflows | Event-driven communication around clear ownership boundaries |
| Very different read and write models | CQRS, but only where the asymmetry justifies the added consistency cost |
| Extensible product with third-party features | Microkernel / plugin architecture |
- Start with the simplest architecture that fits.
- Modularization prevents a big ball of mud; microservices only enforce physical separation.
- Extract a service in response to a genuine need for independent deployment, scaling, ownership, or technology.
- Architecture choices from different rows can be combined.