When integrating multiple external systems, the real challenge is rarely “how to send an HTTP request”—it’s “how to contain the differences.” Each third party has its own API shape, error codes, and rate-limiting policies. If you scatter these differences across the main flow, the code becomes harder and harder to maintain. This is especially common in industries like payment processing (multiple gateways), e-commerce (shipping carriers, logistics), travel (airlines, hotels, OTAs), and marketing (ad platforms, email/SMS providers)—where systems routinely juggle many external integrations. One approach that works well in these contexts: treat each integration as an independent strategy and use a factory to select which one to use at runtime. That way, differences stay isolated in their own implementations, and the main flow only cares about “who to call” and “how to orchestrate,” not the specifics of how to call.

Factory answers the question: which implementation should handle this request? You pass in an identifier—a vendor code, channel type—and the factory returns the corresponding service instance. The main flow doesn’t need to know how many implementations exist or write if-else branches. It just calls the factory, gets an instance, and executes. When you add a new third party, you add an implementation and register it in the factory; the main flow’s code stays untouched. That’s “open for extension, closed for modification”—extension happens at the edges, the core stays stable.

Strategy answers the question: where does this third party’s special logic live? Each third party has its own request format, error parsing, and retry strategy. If you stuff all of that into one giant service, changing A’s logic might affect B, and testing A forces you to pull in B’s dependencies too. The strategy approach: one implementation per third party, implementations independent of each other. Changes to A only affect A; changes to B only affect B. Differences are encapsulated in their own strategies, not spread across the main flow.

Together, the factory handles “which one” and the strategy handles “how to do it.” The main flow depends only on the abstract interface, not concrete implementations. It says “I want to execute this operation,” the factory returns the right service based on the request’s vendor, and the service internally calls the API, parses the response, and handles errors. The main flow doesn’t need to know whether the other side is REST or SOAP, whether error codes are numbers or strings, or what the rate limit is—all of that is absorbed inside each strategy.

Configuration’s role is to pull “things that change” out of the code. URLs, keys, timeouts, polling intervals—these can all vary by environment or business needs. If you hardcode them in implementations, every change requires code edits and redeployment. Put them in config, and you change config instead. That way, implementations only care about “how to use these parameters,” not “where they come from.” When adding a new third party, add a config section, add an implementation, and wire it up in the factory. No need to touch orchestration logic or other existing implementations.

Testing becomes much easier. Because each third party has its own Client and Service, you can mock one in isolation without affecting the others. When a third party’s API is flaky or rate-limited, you can stub just that one while others run real logic. In integration tests, the orchestration layer doesn’t need to know whether the underlying calls are real or mocked—it only depends on the interface. That isolation makes tests more controllable and easier to debug.

They solve different problems at different layers, but they often appear together. Factory solves “selection”—choosing one among many implementations. Strategy solves “isolation”—keeping differences inside their own implementations instead of leaking into the main flow. Configuration solves “variability”—pulling changeable things out of code. It’s hard to handle multi-third-party integration with just one of them: without strategy, differences pile up in the main flow; without factory, the main flow still has to decide who to call; without configuration, every adjustment means code changes. They’re complementary, not optional.