Protocol
Probe the boundary between two components
Do not interrogate the whole chain when one boundary can answer where the bad value first appears.
When it fits
- Several services, interfaces or processing steps could plausibly own the same symptom.
When to avoid it
- A boundary check can be misleading when retries, caches, asynchronous queues or hidden transformations change the path.
Why it matters
Choose a boundary with a defined input and output. Send a known test input or inspect one real transaction on both sides. If the input is correct and the output is wrong, the search moves inward; if the boundary already receives bad data, move upstream. Repeat until the failure domain is small enough to inspect directly.
Steps
- The probe removes at least one component or interface from the active hypothesis set.
An example
Capture the outbound payload from middleware and the inbound payload accepted by the target before debugging either application's entire data model.
Check your result
The probe removes at least one component or interface from the active hypothesis set.
Keep this limit in mind
- A boundary check can be misleading when retries, caches, asynchronous queues or hidden transformations change the path.
Connected ideas
AlternativeBisect a large failure domain
Evidence and sources
Google SRE recommends examining well-defined component interfaces and injecting known test data to check expected transformations.
Interface probes can disturb stateful systems; use safe inputs and preserve context needed to interpret the result.
Effective Troubleshooting · Simplify and reduce