Protocol
Design a fallback at the interface
Interfaces are natural places to define degraded behavior.
When it fits
- When one dependency can fail and take the whole service or process with it.
When to avoid it
- Modularity trades coordination inside a boundary for coordination across interfaces. Do not split systems simply to make diagrams or org charts look cleaner.
Why it matters
Specify timeout, retry, cached value, manual route or safe stop at the dependency boundary, plus the conditions where degraded operation is unacceptable.
Steps
- Name the dependency failure mode.
- Choose safe degraded behavior.
- Define timeout and recovery ownership.
- Test the fallback before needing it.
An example
If an external credit check is unavailable, the process routes to manual review rather than hanging indefinitely or silently approving.
Check your result
A dependency failure produces a known bounded state instead of an improvised reaction.
Keep this limit in mind
- Modularity trades coordination inside a boundary for coordination across interfaces. Do not split systems simply to make diagrams or org charts look cleaner.
Connected ideas
Use beforeCount coordination edges before adding a component
Evidence and sources
Supports
Parnas showed that modularization outcomes depend on decomposition criteria and argued for boundaries that hide changeable design decisions to improve flexibility and comprehensibility.
This is foundational software-design reasoning; organizational adaptations require separate validation.
On the Criteria To Be Used in Decomposing Systems into Modules · Abstract and design comparison