Module 9 — API-Led Architecture
Module 9 — API-Led Architecture
This is very interview-heavy because MuleSoft uses the term API-led connectivity constantly.
The classic three layers are:
Experience API
↓
Process API
↓
System API
The goal is to avoid brittle point-to-point integrations and create reusable boundaries around systems and business processes.
9.1Start with the problem API-led architecture solvesBad architecture:9.2The three layersThink:9.3System APIA System API wraps a backend system.9.4Example Salesforce System APIBackend:9.5Why this is usefulSuppose Salesforce changes:9.6System APIs should be system-orientedA System API shouldn't usually contain giant business workflows.9.7Process APIA Process API implements business orchestration.9.8Example Process APIRequest:9.9Process APIs hide orchestrationThe consumer should not need to know:9.10Experience APIAn Experience API adapts data and behavior for a particular consumer experience.9.11ExampleProcess API returns:9.12Why not let mobile call Process API directly?Sometimes it absolutely can.9.13The canonical pictureMemorize this:9.14Another example: order processingConsumers:9.15What belongs where?A useful decision table:9.16Salesforce System API should hide Salesforce IDs where possibleSuppose Process API only understands:9.17Hide Salesforce field names tooBad Process API logic:9.18Error normalization at System API boundarySalesforce might return:9.19Don't over-hide useful backend capabilitiesThere's also a tradeoff.9.20Reuse is the major goalSuppose three processes need customer data:9.21But reuse has a costIf every internal call becomes:9.22System API as separate deployable app vs reusable subflowThis is an architectural question.9.23Interview trap: “Should every Salesforce call go through a System API?”Don't answer:9.24API-led vs point-to-pointPoint-to-point:9.25API-led doesn't eliminate point-to-point internallyImportant nuance:9.26API contract matters more than implementationSystem API contract:9.27API specificationIn MuleSoft environments you'll commonly encounter:9.28API-first developmentA good workflow can be:9.29APIKitYou may hear:9.30Example APIKit architectureAPI spec:9.31Contract validationIf OpenAPI says:9.32VersioningSuppose:9.33Avoid leaking Process API internals into Experience APIsIf Process API exposes:9.34System API granularityToo fine-grained:9.35Process API granularityBad:9.36Experience APIs may perform presentation-oriented transformationExample:9.37Don't put core business rules in Experience APIBad:9.38Reuse exampleSuppose both:9.39An interview scenarioWe have Salesforce, SAP, and a billing platform. Mobile and web both need a unified customer view. How would you structure it?9.40Another scenarioOnly one internal application talks to Salesforce. Should we create System, Process, and Experience APIs?9.41Performance concernThree layers can mean:9.42Experience → System directly?Yes, potentially.9.43Process → multiple Process APIs?Also possible.9.44APIs vs messagingAPI-led doesn't mean:9.45API ManagementMuleSoft's Anypoint Platform can apply policies around APIs such as:9.46System API securitySuppose the Salesforce System API is internal.9.47Process API shouldn't pass Salesforce auth throughBad architecture:9.48Fault isolationSuppose Salesforce fails.9.49Observability across API layersIf a request traverses:9.50Don't create a “distributed monolith”You can architect 30 Mule APIs that are technically separate but where:9.51Testing each layerFocus:9.52Don't make every automated test end-to-endBad:9.53Contract testing between layersSuppose:9.54API-led connectivity interview definitionIf asked:9.55“What's a System API?”“A reusable boundary around a backend system that hides system-specific schemas, authentication, query language, connector behavior, and…9.56“What's a Process API?”“It implements business logic and orchestration, often combining multiple System APIs into a business capability.”9.57“What's an Experience API?”“It adapts APIs to the needs of a particular consumer or channel—mobile, web, partner, and so on—without duplicating core business logic.”9.58“Does every application need all three?”“No. I'd only introduce separate deployable layers where they provide useful reuse, decoupling, governance, consumer adaptation, or…•Module 9 cheat sheetThe one sentence to remember: