You're the architect reviewing a proposal to build a dedicated anti-corruption layer service in front of a newly launched, actively-co-developed internal 'Catalog' service that another team on the same roadmap owns and is happy to evolve jointly with you. The proposing team argues 'ACLs are always good practice.' How would you push back, and what would make you decide an ACL is NOT worth building here?

## The factors that decide it Deciding whether an ACL is worth building comes down to weighing a small number of concrete factors against each other: 1. how much **influence** you have over the upstream model; 2. how **stable and trustworthy** that model is expected to stay; 3. how much translation **work** the mapping actually requires; 4. how likely the two models are to **diverge** in the future. When a consuming team can sit in the same planning meetings as the producing team, propose changes to the shared model, and expect those changes to land, the 'protection from an untrustworthy foreign model' rationale for an ACL simply doesn't apply — there's no foreign model, there's a jointly-owned one. In that situation, the right tool isn't a translation layer; it's collaborative API design, an API-first or contract-first process, backed by something like consumer-driven contract testing, so both sides agree on a shape and get fast feedback the moment either side's changes would break the other. ## Why 'always good practice' is the wrong frame The reason to push back on 'ACLs are always good practice' is that this treats a targeted, context-dependent pattern as a universal default, which inverts the actual guidance behind it. The anti-corruption layer earns its name specifically because it exists to prevent corruption from a source you cannot control or trust to stay coherent: - a legacy system nobody actively maintains toward your needs; - a third-party vendor whose model changes are unilateral and undocumented; - or an organizational boundary so wide that coordination isn't practical. None of those conditions hold for two teams on the same roadmap actively co-developing a service together; applying the pattern there mistakes 'is an integration point' for 'is an untrustworthy integration point,' and builds costly insulation against a threat that doesn't exist yet. ## What building one anyway costs The cost of building one anyway is concrete and ongoing, not one-time. - While Catalog is actively co-developed, its model will keep changing in ways both teams agreed to and want reflected — every one of those legitimate, wanted changes now has to be **manually re-propagated into the ACL's translator**, which is pure overhead: work that produces zero isolation benefit, because the two models are supposed to track each other closely by design during this phase. - There's also an **opportunity cost** — the engineering time spent maintaining a translator chasing a moving target could instead go toward improving the shared contract itself, or toward the product work the ACL proposal is nominally protecting. - And there's a subtler cost: an ACL creates a **false sense of independence**. The consuming team may start believing changes to Catalog's model are 'safely absorbed' by the ACL and stop paying close attention to Catalog's roadmap, when in reality close coordination is still exactly what's needed while the two services are young and co-evolving. ## Both failure modes The failure mode from **over-applying** ACLs here shows up as duplicated modeling work masquerading as safety: both teams end up maintaining two parallel representations of essentially the same concepts (Catalog's model and the ACL's translated model) that have to be kept in sync by hand, doubling the surface area for a bug where the translator silently falls behind a Catalog change and starts returning stale or wrong values to the consumer — exactly the kind of drift an ACL is supposed to prevent, now caused by the ACL's own maintenance lag instead of by the upstream being untrustworthy. The inverse failure — **not building an ACL** when one was actually warranted — shows up differently: teams keep depending directly on what they assumed was a stable jointly-owned model, and get blindsided later when Catalog is acquired by a different, less cooperative team, opened up to many more consumers with competing needs, or simply outlives its original close working relationship and starts changing in ways this consumer no longer has influence over. The judgment call that actually matters is recognizing when that transition happens and building the ACL retroactively at that point, not reflexively on day one. ## The right call each way A good real-world instance of the right call each way: | The situation | What teams do | |---|---| | Inside a single product organization, two feature teams building complementary services for the same release | typically skip a full ACL and instead use an API-first workflow with consumer-driven contract tests, tools like Pact are built exactly for this — each consumer team writes an executable expectation of the producer's contract, and the producer's CI runs those expectations against every change, which gives fast, automated feedback on breaking changes without building a permanent translation layer | | Contrast that with post-acquisition integration work, where a newly-merged company's legacy order or customer system genuinely fits the 'untrustworthy, uncontrolled, likely-to-be-decommissioned-eventually' profile | there, teams commonly do build a dedicated ACL, sometimes literally as a strangler-fig facade, specifically because the upstream is neither cooperative nor stable, and the isolation is worth its ongoing cost until that legacy system is retired |