System Boundaries and Composition: How Parts Work Together

What a system boundary includes—and leaves out

A boundary helps establish what belongs inside a particular explanation. It does not necessarily describe a physical separation or an independently functioning object.

Consider an online appointment service. For one investigation, the system might include only the scheduling application. For another, it might include the application, confirmation messages, staff calendars, and the people who resolve booking conflicts.

Both boundaries can be useful. They answer different questions.

If the question is why a database query is slow, a narrow technical boundary may be appropriate. If the question is why people arrive for appointments that staff cannot find, stopping at the application’s successful response would exclude important parts of the outcome.

Different kinds of boundaries do different work

An analytical boundary

Defines what an investigation includes. It helps focus an explanation but does not prevent excluded conditions from influencing the system.

An interface boundary

Defines where components exchange something, such as a request, a document, or a status update.

An authority boundary

Limits who or what may make a decision or perform an action.

An operational boundary

Separates environments, resources, or failure domains. For example, two services might run independently but still depend on the same database.

These boundaries may overlap, but they are not interchangeable. A software interface is not automatically a security control. A departmental boundary does not establish who owns every exception. A separate deployment does not prove independence from shared failures.

Choosing a boundary also chooses what may be left unexplained. When an important consequence appears outside the current view, the appropriate response may be to widen the investigation rather than force the consequence into an explanation that cannot account for it.

Composition creates relationships, not just collections

A collection contains parts. A composition connects them through relationships that affect what they can do together.

A document editor, review tool, and publishing service become a publishing workflow when changes and decisions pass between them. Their relationship includes more than the ability to transfer text. It also includes which revision is current, what approval means, and when publication becomes permissible.

Workflow composition therefore involves arranging dependencies and transitions, not simply placing tools in sequence.

Each component operates under assumptions

A component’s behavior usually depends on conditions around it. It may assume that:

• Requests arrive in a particular order.
• An identifier refers to an unchanged object.
• A caller will not repeat an operation unnecessarily.
• A response arrives within an expected period.
• Another component has already checked permission.
• A shared resource remains available.

Composition becomes unreliable when one component depends on a condition that the surrounding process does not actually preserve.

For example, a review tool might correctly approve a specific revision. A publishing service might correctly publish the latest revision. Connecting them through a simple “approved” flag can still publish unreviewed changes. Neither component needs to malfunction for the overall result to be wrong.

Coupling is not inherently a defect

Coupling describes dependency between parts. Some dependency is necessary: a publisher should depend on valid approval when editorial rules require it.

The design question is whether the dependency is understood and appropriate. Does one component need an immediate response from another? Must both share the same definition of a status? Can one change its behavior without disrupting the other?

Reducing coupling can improve flexibility, but it can also introduce delayed information and more complicated coordination. Stronger coordination can preserve consistency while making parts less independently available. There is no universal rule that the loosest connection is always best.

An example: a publishing workflow made of dependable parts

Imagine a workflow with four components:

1. An editor stores article revisions.
2. A review tool records editorial approval.
3. A connector sends publication requests.
4. A publishing service makes the article public.

Each component passes its own tests. The editor saves accurately. The review tool records the reviewer’s decision. The connector sends valid requests. The publisher accepts and displays the supplied material.

Now consider the complete sequence:

1. A reviewer approves revision 12.
2. A writer creates revision 13 with a changed claim.
3. The connector reads the article’s “approved” status and retrieves the latest revision.
4. The publisher makes revision 13 public.
5. The response is lost, so the connector retries the request.

Two composition problems are now visible.

First, approval was attached to one revision while publication selected another. Second, uncertainty about the first request led to repetition. Whether that repetition causes harm depends on the publishing operation: it might harmlessly update the same page, create another page, or repeat a notification.

Define the overall conditions that must hold

Local success checks are insufficient here. The workflow also needs conditions that remain true across its parts:

• The material published must fall within the applicable approval.
• The destination must be the intended site and page.
• A repeated attempt must not create an unintended duplicate effect.
• An uncertain outcome must remain distinguishable from confirmed failure.
• Someone must be responsible for resolving an unresolved publication state.

These are end-to-end invariants: conditions the overall process is intended to preserve, even as work passes between components.

They are not satisfied merely by documenting them. The design needs mechanisms that preserve them, and tests that examine whether those mechanisms hold under relevant conditions.

Possible mechanisms include approval tied to an immutable revision, explicit destination checks, suitable idempotency controls, and a way to verify an uncertain outcome before repeating the action.

The exact implementation can vary. The important point is that the relationship between the parts must preserve the intended result.

What needs to remain clear across an interface

An interface defines how parts interact. It can specify a data format or a callable operation, but useful composition also depends on shared meaning.

Two components can exchange syntactically valid messages while disagreeing about what those messages establish.

Meaning and identity

What does “approved” refer to: an article, an exact revision, or a category of permitted changes? Does a document identifier select a fixed version or whatever happens to be current?

Names and fields need enough precision to preserve the distinctions on which later actions depend.

State and completion

Does “accepted” mean a request passed validation, entered a queue, completed execution, or produced a verified outcome?

A receiving system may acknowledge a request before performing it. A caller that treats acknowledgment as completion can advance the workflow prematurely. This is one reason network success is not necessarily task success.

Time and ordering

Can information arrive late or out of order? Could an older update overwrite a newer one? How long may a decision remain applicable?

An interface that works under immediate, orderly delivery may behave differently when requests are queued, retried, or resumed after interruption.

Failure and recovery

What happens when no response arrives, only part of the work completes, or the receiver becomes unavailable?

The caller needs to know whether it can retry, must verify, or should escalate. A generic error message may conceal a consequential distinction between “nothing happened” and “something may already have happened.”

Authority

Does the request carry evidence of permission, or does the receiver independently check it? Which conditions constrain the action?

A connector’s ability to invoke an operation does not establish that the operation is authorized for every target or circumstance. Credentials provide technical capability; the workflow must still preserve the applicable authority.

Feedback can cross boundaries and change overall behavior

Feedback often travels through several components before influencing the condition that produced it. Looking inside only one component can conceal that loop.

Consider a client that retries slow requests. Retrying may help recover from a transient communication failure. But if many clients retry while a service is overloaded, the extra requests can add load, lengthen delays, and trigger further retries.

The clients are trying to improve their own chance of completion. Together, their behavior may worsen the condition that prompted their response.

This is a system-level interaction, not necessarily a defect in one isolated request.

Local improvements can move the difficulty elsewhere

A queue can keep a receiving service responsive while work accumulates behind it. Faster acceptance may be useful, but it does not establish faster completion.

Similarly, a review team might clear its queue by passing ambiguous cases downstream. Its local throughput improves while the next team inherits more unresolved decisions.

Evaluating composition therefore requires measures of the overall task as well as the individual stages. Where does waiting occur? Where does uncertainty accumulate? Who experiences the consequences?

Emergent behavior is not a substitute for explanation

Behavior is often described as emergent when it arises through interactions among parts rather than belonging to one part in isolation. The term does not mean that the behavior is necessarily mysterious or impossible to investigate.

In the retry example, the mechanism can be described: delays prompt retries, retries add load, and additional load can increase delays. Depending on the system, coordinated retry limits, backoff, admission controls, or other safeguards may reduce the reinforcing effect.

As with any observation and intervention, the response should address the mechanism actually supported by the evidence.

Responsibility must survive the handoff

Technical boundaries often divide implementation work more clearly than they divide responsibility for outcomes.

The sending team may say that it delivered the request. The receiving team may say that it processed what it received. Both statements can be accurate while the intended task remains incomplete.

A dependable composition needs someone responsible for the overall result, together with clear responsibilities at the boundaries. This does not mean one person must perform every step. It means unresolved work should not disappear between local definitions of completion.

Acceptance should make the next obligation clear

A useful handoff establishes what was transferred, what the receiving party accepted, what remains uncertain, and who must act next.

For example, “Publication request accepted; outcome pending” is more informative than “Done.” If confirmation does not arrive, the process should identify who investigates and what evidence is needed before another attempt.

Intervention controls have boundaries too

A local pause may stop new requests without stopping requests already queued elsewhere. Disabling a connector may not cancel work the publisher has already accepted.

The scope of a control must therefore be understandable. What does it stop? What can continue? What may already have happened?

Governance during execution keeps these operational facts connected to authority and responsibility. A visible warning is not enough if another execution path can proceed around it.

A practical review of system composition

Choose one meaningful outcome and trace it across the parts that contribute to it. Include people and external services where they affect completion, permission, or recovery.

1. State the overall outcome. Describe what must be true for the task to count as successful—not merely for each component to finish.
2. Draw the relevant boundary. Include dependencies that could materially change that outcome. Record important exclusions.
3. Trace the exchanges. Follow requests, data, decisions, acknowledgments, and feedback across each interface.
4. Compare assumptions. Check whether what one component expects is actually provided by the others.
5. Identify shared dependencies. Look for resources or services whose failure could affect several apparently separate parts.
6. Test disrupted conditions. Examine delay, duplication, reordered messages, partial completion, unavailable participants, and changed targets where relevant.
7. Inspect authority and ownership. Establish who may proceed, who can intervene, and who must resolve an uncertain outcome.
8. Verify the whole result. Check the final state and consequential side effects, rather than relying only on local success messages.

Component tests remain valuable. They establish behavior within their scope. Integration and end-to-end tests add evidence about selected interactions and complete paths, but no single test establishes dependability under every possible condition.

The aim is not to erase boundaries or make every component know everything. Good boundaries can limit complexity, protect resources, and support independent work.

Dependable composition preserves those useful separations while making the connections clear enough that meaning, authority, and responsibility do not get lost between the parts.