Concept · Computing
Reasoning about distributed systems boundaries
A compact mental model for identifying where independently changing components become a distributed-systems problem.
The idea
A distributed-systems problem begins when a useful boundary separates components that can no longer rely on shared memory, shared timing, or a single failure domain. The important question is not whether a diagram has arrows; it is what each side is allowed to assume.
A page should remain understandable when reached directly from search, a sketch, a case study, or the Semantic Atlas.
Why boundaries matter
Boundaries make uncertainty visible. Messages can be delayed, duplicated, reordered, or lost. A caller can observe a timeout even when the callee eventually completes. Those conditions turn an ordinary function-shaped dependency into a contract that needs explicit behavior.
type Boundary = {
request: string;
response: string;
retryPolicy: 'safe' | 'conditional' | 'forbidden';
};Questions to ask
- Which component owns the decision?
- What can be retried safely?
- Which failure is visible to the caller?
- What evidence lets an operator distinguish delay from loss?
| Question | Useful signal |
|---|---|
| Can this operation repeat? | An explicit idempotency contract |
| Can it fail independently? | A named failure domain |
| Can it be repaired later? | Durable state and a recovery path |
Sources and further reading
The references and related reading controls are structured separately from the Markdown body. That keeps the document readable while allowing the library to build stable reading context around it.
References and sources
Further reading.
- Fixture reading on system models ↗Synthetic reference for the prototype.