Cloud Computing Architecture Guide

Distributed Systems as Boundaries and Commitments

Goal

Establish why distribution changes communication, state, failure, and ownership, and when that cost buys useful independence.

The Short Version

Moving an in-process call across a network removes assumptions that local code quietly provided. The call can be slow, time out after succeeding, arrive twice through retry, or reach a component running a different version. The caller and receiver can observe different facts. Operations must correlate behavior across both sides.

Distribution is worthwhile when it creates valuable independence: separate deployment, scaling, security, availability, technology, or team ownership. Component count is not a measure of maturity.

What a Network Boundary Adds

In process                 Across a network
-----------                ----------------
one failure context        partial failure
shared transaction         explicit consistency model
direct call stack          timeout, retry, and correlation
one deployed version       contract evolution
local debugging            distributed evidence

Every boundary creates four commitments:

  1. Communication: protocol, contract, timeout, retry, and overload behavior.

  2. State: authority, consistency, transaction scope, and reconciliation.

  3. Failure: detection, containment, recovery, and degraded behavior.

  4. Ownership: who changes, operates, secures, and pays for the boundary.

If a proposed service cannot answer those questions, it is probably a code split rather than an architecture boundary.

Choose the Smallest Useful Boundary

A modular monolith can preserve clear business modules and ownership inside one deployable. An asynchronous worker can isolate slow or bursty work without creating a broad service estate. A network service is justified when independent behavior is valuable enough to fund contracts, telemetry, delivery automation, security controls, and on-call capability.

Start together when uncertainty is high and separation has no proven benefit. Preserve internal seams so the team can split later with evidence. This is not anti-microservice; it is pro-explicit economics.

Example: Catalog and Ordering

Catalog and ordering modules initially deploy together. Catalog reads dominate traffic, but releases and ownership remain shared. A modular boundary is sufficient.

Later, catalog traffic grows independently, pricing updates need a different release cadence, and a dedicated team takes ownership. Separation now creates measurable value. The teams define an API, isolate catalog state authority, publish compatible product-change events, and add independent objectives and telemetry. The network boundary follows an operating boundary rather than pretending to create one.

Common Mistakes

  • Treating more deployables as automatic maturity.

  • Splitting code while retaining shared writes and coordinated releases.

  • Ignoring the delivery, identity, telemetry, and on-call platform distribution requires.

  • Using synchronous chains that recreate a monolith's coupling with network failure added.

  • Claiming independent scaling without identifying the actual bottleneck.

If Someone Asks You

When is a distributed boundary worth its cost?

"When independent deployment, scaling, security, resilience, or ownership has concrete value that exceeds the cost of network communication, consistency, operations, and contract evolution. Otherwise I prefer a strong modular boundary inside a simpler deployment."

What You Should Remember

Distribution is justified by valuable independence, not by component count.

Questions to Check Your Understanding

  1. Which guarantees change when a call crosses a network?

  2. What evidence could justify separating two modules?

  3. How can a system be modular without being distributed?

Further Study