A staff engineer is deciding whether to introduce an Anti-Corruption Layer for a new microservice's integration with an external partner API. What are the concrete costs versus benefits they should weigh before committing to it?

## Naming both sides of the ledger Deciding whether an integration warrants an Anti-Corruption Layer is fundamentally a **cost-benefit judgment**, and the calculation only makes sense once both sides of the ledger are named concretely rather than treated as vague pattern-hygiene. ## The benefits On the benefit side, the primary win is **isolation** of the new domain model. Every field name, status code, unit convention, and null-handling quirk of the external system stays confined to the translator instead of spreading through business logic, tests, and API contracts across the new codebase. This isolation pays off doubly when the external system is genuinely messy (inconsistent legacy naming, undocumented edge cases) or actively evolving (a partner API under active development, a vendor who ships breaking changes), because every future adaptation to that mess is a change in one place instead of a search-and-replace across every consumer. - A closely related benefit is **reduced blast radius**: if the external system has an outage, a data-quality bug, or a breaking API change, the ACL is the single place to add a workaround, a circuit breaker, or a compatibility shim, rather than patching a dozen call sites. - Finally, an ACL makes **eventual replacement** of the external system cheaper - if the partner API, or a legacy system behind it, is swapped out for something else years later, only the ACL's adapter and translator need to change, because the rest of the codebase only ever depended on the ACL's own stable facade contract. ## The costs 1. On the cost side, the first and most visible cost is simply **more code**: a facade interface, adapter(s), and translator(s) that all need to be written, reviewed, and tested, on top of whatever code would have been needed to call the external system directly. 2. The second, more insidious cost is **double maintenance**: the translator has to track both the external system's evolving shape and the new system's evolving domain model, so a schema change on either side can silently break the mapping, and someone has to notice and fix it - this is ongoing cost for the life of the integration, not a one-time build cost. 3. Third, there's a real **performance cost**: an extra hop (even if in-process) adds some latency, and if the ACL runs as its own deployed service, it adds a network round trip, a new failure mode to handle (the ACL itself can be down or slow), and another component to monitor and operate. 4. Fourth is an **organizational risk**: if ownership of the ACL isn't clearly assigned, it tends to accrete unrelated logic from whichever team touches it most recently, slowly turning into exactly the kind of tangled, poorly-understood component it was built to protect against - at that point it has stopped paying for itself. ## The questions that decide it The judgment call, then, hinges on a handful of concrete questions rather than a blanket rule. - **How messy or inconsistent is the external model** relative to the new system's domain language - if they're already close, an ACL adds cost with little corruption risk to prevent. - **How likely and how frequent are breaking changes** on the external side - a stable, well-versioned partner API that rarely changes needs less protection than a legacy system maintained by a shrinking team with no backward-compatibility discipline. - **How many independent consumers will call this integration** - a single, small, short-lived integration touched by one team rarely justifies the overhead, while an integration consumed by five teams over several years usually does. - **How strategically important is eventual decoupling** from this external system - if there's a known plan to migrate off a legacy system in eighteen months (a strangler-fig migration), the ACL earns its cost by being the only thing that needs rewiring on cutover day. ## A useful heuristic A useful heuristic some teams use: apply an ACL where the integration is expected to be long-lived, multi-consumer, or where the external model is known to be unstable or foreign to the domain; skip it for a small, short-lived, single-consumer call to a well-behaved, stable API, where a thin, honestly-typed client wrapper without a full translation layer is enough. Treating the ACL as free architectural hygiene to apply everywhere, rather than as a deliberate cost/benefit trade, is itself a common mistake - it produces unnecessary indirection on integrations that never needed protecting in the first place, and it dilutes the pattern's credibility when a genuinely risky integration actually needs it.