Countering Integration Point Problems

Learn about stability patterns to fight integration point failure, emphasis on testing different flows, and some important points for integration setup.

Integration point failure

A stand-alone system that doesn’t integrate with anything is rare, not to mention being almost useless. What can we do to make integration points safer? The most effective stability patterns to combat integration point failures are Circuit Breaker and Decoupling Middleware.

Cynical software

Testing helps, too. Cynical software should handle violations of form and function, such as badly formed headers or abruptly closed connections. To make sure our software is cynical enough, we should make a test harness, a simulator that provides controllable behavior for each integration test (see Test Harnesses).

Simulate network failures

Setting the test harness to spit back canned responses facilitates functional testing. It also provides isolation from the target system when we’re testing. Finally, each such test harness should also allow us to simulate various kinds of system and network failures.

This test harness will immediately help with functional testing. To test for stability, we also need to flip all the switches on the harness while the system is under considerable load. This load can come from a bunch of workstations or cloud instances, but it definitely requires much more than a handful of testers clicking around on their desktops.

Tips to remember

Beware this necessary evil

Every integration point will eventually fail in some way, and we need to be prepared for that failure.

Prepare for the many forms of failure

Integration point failures take several forms, ranging from various network errors to semantic errors. We will not get nice error responses delivered through the defined protocol. Instead, we’ll see some kind of protocol violation, slow response, or outright hang.

Know when to open up abstractions

Debugging integration point failures usually requires peeling back a layer of abstraction. Failures are often difficult to debug at the application layer because most of them violate the high-level protocols. Packet sniffers and other network diagnostics can help.

Failures propagate quickly

Failure in a remote system quickly becomes your problem, usually as a cascading failure when our code isn’t defensive enough.

Apply patterns to avert integration point problems

Defensive programming with Circuit Breaker, Timeouts, Decoupling Middleware, and Handshaking will all help to you avoid the dangers of integration points.

Get hands-on with 1200+ tech skills courses.