Skip to main content

Boundary-Blind Integration

A Failure Pattern of Invisible Boundaries and Cascading Failure

Summary​

Boundary-Blind Integration is a Failure Pattern in which integration proceeds without making boundaries explicit with external systems, other teams, asynchronous processing, etc., and the impact of failures and changes expands cascadingly.

What this Pattern addresses is not the appropriateness of distribution or integration itself. Rather, it depicts a structure in which, in the process of proceeding with integration, choices not to consciously consider boundaries rationally accumulate, and as a result, "how far is our responsibility" cannot be judged.

Context​

Modern software rarely stands complete as a single system.

External APIs, SaaS, services managed by other teams within the company, asynchronous jobs, event-driven processing, and so on— functions hold across multiple boundaries.

These integrations look simple in the initial stage and are often handled with the same sense as internal calls. However, when expanded without boundary conditions being made explicit, the behavior of the system as a whole becomes hard to grasp.

Forces​

The main dynamics that generate this Pattern are as follows:

  • Ease of integration
    Through development of SDKs and libraries, connection with the outside becomes as easy as internal implementation.

  • Expansion of success experience
    From the experience of the first integration working without problems, integration increases without reconsidering boundary conditions.

  • Ambiguity of responsibility boundaries
    When failures and delays occur, it is hard to judge how far is one's own responsibility.

  • Invisibility of asynchronous/distributed processing
    The order and failure of processing do not surface easily, and problems manifest with delay.

Failure Mode​

When boundaries are not made explicit, it becomes hard to limit and capture the scope of impact of failures and changes.

As a result, the following forms of breaking proceed simultaneously:

  • Partial failures are not treated as assumptions
    Timeouts and temporary failures are handled as exceptions and not incorporated into happy-path design.

  • Separation of responsibility becomes difficult
    When problems occur, causes fluctuate on the boundary, making it hard to determine the starting point for response.

  • Observation paths are buried in external factors
    Logs and metrics are fragmented across boundaries, making it hard to track causal relationships of failures.

Consequences​

  • Failure response becomes intermittent and load tends to accumulate
    (Part I: What Breaks — Operation / Time)

  • The scope of change impact becomes hard to explain, and decisions lean toward caution
    (Part I: What Breaks — Boundary / Responsibility)

  • Operational costs rise and improvement tends to be deferred
    (Part II: Why It Breaks — Measurement Gap)

  • Decisions about distributed configurations lean toward conservatism, and design choices tend to become fixed
    (Part II: Why It Breaks — Decision Avoidance)

Countermeasures​

The following are not a list of solutions, but counter-patterns for treating boundaries as design decisions against Failure Mode.

  • Define boundaries as branching points of responsibility and assumptions
    Make boundaries explicit as points where decisions change, not as implementation details.

  • Position partial failures as normal cases
    Treat failures and delays not as exceptions, but as assumptions to be woven into design.

  • Have structures that suppress decisions crossing boundaries
    Adopt designs that prevent processing or decisions from propagating without limit during failures, so they do not cross boundaries.

Resulting Context​

Integration remains necessary, and returning everything to a single system is not realistic.

However, by making boundaries visible, failures are localized and scope of impact can be limited.

For example, during external API failures, one can choose at the boundary whether to continue or stop internal processing, and in asynchronous processing, one can design behavior locally on the assumption of delay or omission.

As a result, distribution and integration are treated as controllable design decisions and reconstructed as structures that can withstand change and operations.

See also​

  • Retry-as-Recovery
    A derived pattern in which failures on boundaries are treated as if recovered by re-execution, without being localized.

  • Test-Passing Illusion
    A structure in which distributed/asynchronous assumptions do not appear in verification environments, and limited success becomes a proxy indicator of correctness.

Appendix: Conceptual References​

Appendix: References​

  • David L. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, 1972.
  • Fred Brooks, No Silver Bullet—Essence and Accidents of Software Engineering, 1987.
  • Donella H. Meadows, Thinking in Systems: A Primer, 2008.
  • James O. Coplien, Neil B. Harrison, Organizational Patterns of Agile Software Development, 2004.
Last updated on by Hiroshi Kurabayashi