MGWC common mistakes
MGWC · Understand the traps and how to avoid them.
When asked to document an integration architecture, the candidate draws only a component diagram (systems and arrows) and omits the interface catalog, data ownership, protocol/contract per hop, and the non-functional requirements that drove the design.
Candidates equate 'architecture documentation' with a picture. They have practiced drawing flows in Anypoint Studio but never practiced producing the written artifacts (interface inventory, sequence of interactions, assumptions, constraints) that a reviewer needs to validate the design.
What to do instead
Before writing, build a checklist of required artifacts: context diagram, component/interface inventory with owner system, protocol and payload per interface, sync vs async decision per hop, error and retry contract, and NFR table (throughput, latency, availability, RPO/RTO). Answer the question by naming which artifact addresses which concern, and state explicitly what is out of scope.
The candidate treats API-led connectivity as three fixed tiers to be applied to every problem, so a simple point-to-point file drop or a single-system CRUD API gets wrapped in a System API, Process API, and Experience API with no justification.
Training material presents the three layers as a model to memorize, and candidates reproduce the layer names as a template rather than as a decision heuristic. They do not articulate the criteria (reuse potential, consumer diversity, rate of change, ownership boundaries) that justify each layer.
What to do instead
For each candidate API, state the reason it exists as a layer: System APIs for bounded access to a system of record and to isolate change; Process APIs for orchestration and business logic reused across channels; Experience APIs for channel-specific composition and contract shaping. Where a layer adds no reuse or isolation value, say so and collapse it, and note the trade-off you accepted.
The candidate describes API Manager policies as configuration applied globally and forgets that policy scope, ordering, and enforcement point (API gateway vs runtime) determine behavior, so answers misstate where a policy actually executes and what it can see.
Policies are easy to list (rate limiting, OAuth 2.0 token enforcement, IP allowlist, JSON threat protection) but candidates rarely reason about the request path: which policies run before the payload is parsed, which can inspect headers only, and what happens when a policy is applied at the instance level versus the group level.
What to do instead
Practice explaining a single request end-to-end through the gateway: authentication and token validation first, then throttling, then threat protection on the body, then routing to the implementation. For each policy state what it inspects, where it is enforced, and what error contract it returns to the client. Call out that policy order and scope are design decisions, not defaults.
When asked about reliability, the candidate answers only 'use retries' and does not distinguish idempotency, dead-letter handling, redelivery semantics, and backpressure, nor does the candidate match the reliability mechanism to the transport (HTTP synchronous call vs VM/JMS queue vs Anypoint MQ).
Retry is the first pattern learned and the easiest to name. Candidates have not internalized that retrying a non-idempotent POST creates duplicates, that retries without backoff and jitter amplify an outage, and that a queue-based flow needs a DLQ and a replay procedure rather than a retry loop.
What to do instead
Structure the answer as: failure classification (transient vs permanent), idempotency key strategy, retry policy with backoff and max attempts, dead-letter destination and alerting, and reconciliation for messages that exhaust retries. Explicitly say which connector/transport provides at-least-once versus exactly-once behavior and what the flow must do to compensate.
The candidate designs error handling as a single global error handler that returns a generic 500, without mapping downstream faults to distinct client-facing status codes, without separating system vs validation vs connectivity errors, and without a correlation identifier in the response.
Studio scaffolds a default error handler, so candidates accept it. They also conflate 'the flow failed' with 'the caller should get a 500', forgetting that a downstream 404 or a schema validation failure is a caller problem, not a server fault.
What to do instead
Use on-error-propagate and on-error-continue deliberately: continue for recoverable enrichment failures, propagate for fatal ones. Map error types (validation, connectivity, security, not-found, timeout) to HTTP status and to a stable error payload with code, message, and correlationId. State where the correlationId is generated and that it is logged and returned.
The candidate writes DataWeave that works for the sample payload but ignores nulls, missing fields, arrays versus single objects, and namespace handling in XML, and does not describe how the transformation behaves on the actual edge cases.
Practice happens against clean fixtures. Candidates rarely rehearse defensive DataWeave: default values, coalescing, conditional mapping, and the difference between a field being absent and being present with a null value. XML namespaces in particular break naive selectors.
What to do instead
For every mapping, enumerate the source contract's optional fields and state the target default. Use default and conditional operators explicitly, handle single-object-to-array coercion, and declare namespace handling for XML. Mention where validation belongs (schema or JSON schema validation) so transformation is not silently absorbing bad data.
The candidate describes securing an API as 'use HTTPS and OAuth', without distinguishing authentication from authorization, without describing token validation (introspection vs local validation, scopes, audience), and without covering secrets management and transport security for the backend hop.
Security answers are memorized at the buzzword level. Candidates do not connect the policy configuration to the actual trust boundaries: who issues the token, what the gateway validates, what identity is propagated downstream, and how client credentials and keystores are stored per environment.
What to do instead
Answer along the trust chain: client authenticates to the identity provider, gateway validates token signature/expiry/audience and enforces scopes, identity or client context is propagated to the backend, backend-to-backend calls use their own credentials from a secrets store. Add transport security, input threat protection, and mention that secrets never live in source control.
The candidate treats deployment as a manual Studio publish and cannot describe the promotion path across environments, the role of the application and API instance configuration per environment, or how property placeholders and environment-specific endpoints are externalized.
Local development hides the operational reality. Candidates have not practiced explaining that the same deployable artifact is promoted with different configuration, that API Manager instances and contracts differ per environment, and that automated pipelines need credentials scoped to each environment.
What to do instead
Describe the pipeline stages: build and unit test, publish artifact to the repository, deploy to the lower environment, run integration tests, promote the same artifact with environment-specific properties, register or update the API instance, apply the policy set, and run smoke tests. Name where each environment's secrets and endpoint values come from and who approves promotion.
The candidate answers scalability questions with 'add more replicas' and does not discuss the stateful parts of the flow: connection pool sizing, streaming large payloads versus buffering, batch job chunking, and the downstream system's capacity as the real constraint.
Horizontal scaling is the reflexive answer, but integration throughput is usually bounded by the slowest backend and by memory behavior on large payloads. Candidates do not reason about object store usage, streaming, or the difference between a synchronous fan-out and an async decoupled design.
What to do instead
Identify the bottleneck first: backend connection limits, payload size and memory, or synchronous call chains. Then propose matching tactics: pool sizing aligned to backend limits, streaming for large files, batch processing with chunk sizes and checkpointing, caching for reference data, async queues to absorb bursts, and rate limiting to protect the backend. State the metric you would watch to confirm the fix.
The candidate answers 'how do you keep environments consistent' by describing separate hand-maintained API specifications and copies of the flow per environment, leading to drift between the design contract and what is actually deployed.
Candidates separate the design phase (spec-first) from the implementation phase and never link them. They do not mention that the API specification should be the source of truth, validated against the implementation, and versioned with the artifact so contract and behavior cannot diverge.
What to do instead
Make the specification the contract: design it first, generate or scaffold from it, validate the implementation against it in the pipeline, and version it alongside the artifact. Describe how breaking changes get a new major version and a deprecation window, and how consumers are notified through the developer portal rather than by email.