Simplicity & complexity budget
Simplicity keeps a design understandable and operable. A complexity budget makes visible which additional mechanisms are used for proven requirements.
- Evidence of needMechanisms need proof.
- Ongoing costsEach mechanism permanently costs understanding and operation.
- BudgetThe team can only carry limited complexity.
Context
Why this is important
Each additional mechanism incurs ongoing costs in communication, consistency and operation. Without a proven need, it becomes a burden. Simple is not easy (Rich Hickey, "Simple Made Easy"): simple means not intertwined, easy means familiar. Where complexity comes from, the building block deals with complexity.
This building block explains the conscious choice of additional mechanisms. For the origin of different types of complexity see Complexity.
At a glance · Mechanisms against the complexity budget
What does the shop spend its complexity budget on?
The shop team checks whether order and invoice require separate services. They are currently working in a modular monolith with joint release.
This is how you read the picture
- Evidence of need The label ‘occupies’ or ‘presumed’ on each mechanism with its justification.
- Ongoing costs The points per mechanism: from the cache with 1 Until the event sourcing with 4.
- Budget The bar against the capacitance 10: It fills with every mechanism connected.
4 of 10 PointsWhat the small shop team can understand and operate
Still 6 Points Free. Everything that is spent is documented.
Values illustrative
What does the additional mechanism cost?
| Criterion | Modular monolith today | Separate services (variant) |
|---|---|---|
| Evidence of need | Joint release is enough | Only for independent releases |
| Communication | Local module contract | Network Contract and Error Semantics |
| Data consistency | A local transaction for B-1042 | Distributed vote needed |
| Operations | A process | Multiple deployments and observation |
| Choice for the shop | Sufficient | Benefits not currently proven |
Benefits & limitations
Helps if:
- A small team needs a viable start with manageable operation.
- A design adds platforms or abstractions in anticipation of needs whose benefits are still unclear.
Boundaries
- Simple does not mean structureless: too little structure is also expensive and ends in the “Big Ball of Mud”. Simplicity requires discipline, for example through Module boundaries.
- An initially simple design may reach its limits as needs grow. Monitor measurable drivers; Trade-off Analysis shows when a targeted extension is worthwhile.
In practice
- Identify current task and obstacle. Describe the need that needs to be solved now. The result separates proven requirements from suspected later extensions.
- Choose the smallest viable design. Meet quality goals and constraints with the most manageable structure. Compare any additional mechanisms by their cost and Complexity.
- Observe effects and pressure for change. Define what measurement or experience would justify an extension. Trade-off Analysis connects new load or team responsibilities to an appropriate structure.
Read the detailed explanation
A simple design is easy to explain, change and operate in its context. It keeps necessary business rules visible and adds technical mechanisms when they meet a demonstrated need. Complexity distinguishes necessary rules from additional effort; Trade-off Analysis weighs benefits against costs.
Simplicity is reflected in how easily real tasks can be understood, changed and operated; the number of files or technologies alone is not a useful measure. An additional platform may complicate operations, while a clear module boundary may simplify them. Monitor change, load and operational requirements, and adapt the design as demonstrated needs evolve.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
How many points do the three proven mechanisms cost together?
View the solution with justification
4 from 10 Points: Module boundaries 1Queue 2 and Cache 1. Remaining 6 Points reserve.
ApplyingTransferred to a new situation
The invoice team wants to deliver independently of the order from now on. What changes in the evaluation?
View the solution with justification
This creates the need for "independent releases", which can justify separate services according to the line of occupied need. Then network contracts, error semantics and several deployments are planned.
EvaluateWeighing an alternative
The team wants to separate services as a precautionary measure in order to be more flexible later on. How do you weigh up?
View the solution with justification
Advantage: later separation would be prepared. Disadvantage: network contract, distributed voting and several deployments are to be carried immediately, the benefit is currently not proven. Better: wait until the need is established.
Explore further
These building blocks continue the thoughts of this page.
References
- Martin Fowler · YAGNI (opens in new tab)Explains the cost of precautionary built-in functions and abstractions.
- Google SRE · Simplicity (opens in new tab)Explains operational costs of complexity and clear system design.
- Martin Fowler - Monolith First (opens in new tab)Explains the step-by-step path to stable module and service boundaries.
- Rich Hickey - Simple Made Easy (InfoQ) (opens in new tab)It is easy to distinguish (not intertwined) from easy (familiar).