In a production system, an Anti-Corruption Layer sits in front of a flaky third-party API and has been running fine for months. What are the most likely ways this kind of layer fails or degrades in production, and how would you design against each one?

## Translation drift An Anti-Corruption Layer that has been quietly working for months is not evidence it's safe - it usually means the failure modes haven't been triggered yet, because most of them are triggered by change on the far side of the boundary rather than by steady-state traffic. The most consequential failure mode is **translation drift**: the external or legacy system changes its response shape (a renamed field, a new status code, a changed date format) without the ACL team being notified, and if the translator wasn't written defensively, it doesn't throw an error - it maps the unfamiliar value to whatever the code happens to fall through to (often a default or null), producing domain objects that are subtly wrong rather than obviously broken. This is dangerous precisely because it doesn't look like an outage: requests succeed, response codes are 200, and the bad data only surfaces downstream as a business-logic bug, a wrong report, or a customer complaint, often days or weeks after the actual upstream change. - **The defense** is to make translators fail loudly on anything they don't explicitly recognize - raise a typed error or emit a distinct 'unmapped value' metric rather than silently defaulting - paired with contract tests that run against captured real payloads from the external system and are re-validated whenever that system's team announces a change, if such notice even exists. ## An availability and latency bottleneck A second failure mode is the ACL becoming an availability and latency bottleneck for everything behind it. Because every consumer is funneled through the same facade, a slowdown or outage in the external system, or in the ACL's own process, now affects every consumer simultaneously, whereas before the ACL existed, at least some consumers might have had independent (if uglier) integrations. This is compounded if the ACL doesn't apply its own timeouts and circuit breakers: a slow legacy system can tie up the ACL's connection pool or thread pool, and that exhaustion then cascades to every consumer waiting on the ACL, turning one flaky dependency into a much wider outage. - **The defense** is to treat the ACL like any other dependency a resilient system talks to - explicit timeouts shorter than the caller's own budget, a circuit breaker that fails fast once the external system is clearly unhealthy, and where the data allows it, a cache or last-known-good fallback so transient external outages don't propagate as user-facing failures. ## Chatty or N+1 translation A third, easily overlooked failure mode is chatty or N+1 translation: a well-intentioned facade method like `getOrders(orderIds: List)` gets implemented by looping over the IDs and calling the legacy adapter once per ID, because the legacy system's own API is single-item, and nobody optimizes the translator to batch. Under low load this is invisible; under real production volume it turns a single logical operation into hundreds of external calls, multiplying latency and load on the fragile downstream system exactly when it's least able to absorb it. - **The defense** is to design the adapter layer to batch aggressively where the legacy protocol allows it, and where it doesn't, to be explicit (in code review and in monitoring) about the N+1 shape so it's a deliberate, bounded trade-off rather than an accidental one that only gets discovered under a load spike. ## Scope creep A fourth failure mode is organizational rather than technical: **scope creep**. Because the ACL sits at a convenient shared chokepoint, teams under deadline pressure tend to bolt unrelated logic onto it - caching for an unrelated feature, authorization checks that belong elsewhere, business rules that have nothing to do with translating the legacy model - especially when the ACL has no single clear owner. Over months or years this turns the ACL into exactly the kind of tangled, hard-to-change component it was built to prevent, and by the time anyone notices, untangling it is its own migration project. - **The defense** is mostly organizational discipline: assign explicit ownership, document what belongs inside the boundary (translation and only translation) versus what doesn't, and treat proposals to add unrelated logic to the ACL with the same scrutiny a team would apply to adding unrelated logic to any other well-scoped service. ## One story that ties several together A concrete example that ties several of these together: a payments team's ACL in front of a third-party processor worked fine for a year, until the processor rolled out a new fraud-status enum value during a minor API update. The translator, written to default unrecognized statuses to 'approved' rather than erroring, silently approved a batch of transactions that should have been flagged, and the bug was only caught when reconciliation numbers didn't match days later - a textbook case of translation drift compounded by a fail-silent default, and exactly the class of bug that contract tests and loud failure on unmapped values are designed to catch before it reaches production traffic.