Thirty system APIs and a slow experience API. What we ask MuleSoft candidates

This is the scenario we put to MuleSoft candidates, published in full on the role page. It looks like a performance question. Underneath, it is a question about architecture and ownership, which is why the obvious answer is the weak one.

An API-led implementation has thirty system APIs, four process APIs and one experience API. Latency on the experience API is unacceptable and the team wants to add caching. What do you ask first?

The trap in the question

The scenario hands the candidate a fix — caching — and a tool that makes it easy. A caching policy is a few clicks away in the API management layer, so the question quietly rewards whoever reaches for it first. But nothing in the scenario says the latency comes from repeated identical requests. It says there are thirty-five APIs between the consumer and the data, and the experience layer is slow.

What a senior answer contains

• Asks where the time actually goes before proposing a fix — and specifically how many of those hops are sequential. Thirty system APIs called in parallel and thirty called one after another are different latency problems.
• Questions whether the process layer is orchestrating or just forwarding. In an API-led design the process layer should compose and orchestrate. When it only passes calls through, it adds a hop to every request without adding value, and that is the usual cause of this symptom.
• Knows that caching moves the problem when the payload is personalised, and asks what varies per request. A response that differs per user or per account either caches badly or caches dangerously.
• Talks about who owns each API and how deprecation works, because at thirty APIs that is the real constraint. Any fix that changes a system API's contract has to survive the consumers that depend on it.

Where a mid answer stops

• Reaches for the caching policy because it is available in API Manager. Availability is not a diagnosis.
• Cannot say which layer owns transformation versus orchestration, which means they cannot say where the latency should be fixed.
• Has not had to deprecate a system API that four consumers depend on. That experience is what turns a layered diagram into something that can actually change.

The wider point

Integration platforms make the quick fix easy, which is exactly why this screen is built around one. The engineers worth placing find out where the time goes first, and understand that in a network of thirty APIs the hardest constraint is usually people and contracts, not code.