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.4codeExample 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.8codeExample 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.11codeExampleProcess 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.17codeHide Salesforce field names tooBad Process API logic:9.18codeError 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.23Q&AInterview 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.26codeAPI contract matters more than implementationSystem API contract:9.27codeAPI 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.33codeAvoid leaking Process API internals into Experience APIsIf Process API exposes:9.34System API granularityToo fine-grained:9.35Process API granularityBad:9.36codeExperience APIs may perform presentation-oriented transformationExample:9.37Don't put core business rules in Experience APIBad:9.38Reuse exampleSuppose both:9.39Q&AAn 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.54Q&AAPI-led connectivity interview definitionIf asked:9.55Q&A“What's a System API?”“A reusable boundary around a backend system that hides system-specific schemas, authentication, query language, connector behavior, and…9.56Q&A“What's a Process API?”“It implements business logic and orchestration, often combining multiple System APIs into a business capability.”9.57Q&A“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.58Q&A“Does every application need all three?”“No. I'd only introduce separate deployable layers where they provide useful reuse, decoupling, governance, consumer adaptation, or…•cheat sheetModule 9 cheat sheetThe one sentence to remember: