The three-layer model, and where it breaks
API-led connectivity divides an integration estate into system APIs that expose sources of record, process APIs that orchestrate business logic, and experience APIs that shape data for specific consumers. The model is sound. What breaks it, consistently, is boundary erosion: an experience API that reaches directly into a system of record because a deadline was tight.
Once that happens twice, the layer model becomes documentation rather than architecture. Enforcement therefore has to be automated — network policy, API governance rules, and deployment gates that reject a consumer calling across two layers.
Designing system APIs that outlive their backends
A system API's job is to insulate the estate from the source of record, which means its contract must not leak backend implementation detail. Field names, enumerations, and error semantics should reflect the business domain, not the underlying table schema or mainframe copybook.
This is the difference between an estate that can absorb a core-system replacement and one where every downstream consumer must be rewritten. The cost of the abstraction is paid once; the cost of omitting it is paid at every migration.
Throughput, worker sizing, and backpressure
Scalability problems on Anypoint deployments usually trace to one of three causes: synchronous chaining of process APIs, insufficient backpressure between tiers, or connection-pool exhaustion against a slow downstream system. All three appear healthy under functional testing and fail under production concurrency.
The remedy is to load-characterise each layer independently, establish explicit concurrency limits, and convert long-running orchestrations to asynchronous patterns with durable state. Circuit breakers belong at every external boundary, with fallbacks defined by the business rather than by the engineer on call.
Governance, reuse, and the asset catalogue
The promised benefit of API-led connectivity is reuse, and reuse depends entirely on discoverability. An asset catalogue with meaningful descriptions, worked examples, and clear ownership converts APIs into products. Without it, teams rebuild what already exists.
Mature estates publish reuse metrics alongside uptime metrics. When a platform team can show that a new consumer onboarded in days rather than months because three existing process APIs were composed, the architecture justifies itself in terms the business recognises.