Module 17 — Interview System-Design Scenarios
This module is where we stop learning components one by one and practice answering:
“How would you design this Mule integration?”
For these questions, the interviewer usually cares less about exact XML and more about whether you naturally think about:
contract
data flow
dependencies
Salesforce model
sync vs async
volume
error handling
idempotency
security
testing
operations
A strong answer should sound structured rather than improvised.
17.1Your default system-design frameworkWhen they give you a scenario, mentally walk through this sequence:•Scenario 1 — REST API creates/updates a Salesforce customer“Build an API where another application sends customer information to Mule and Mule creates or updates the Account in Salesforce.”17.2Start by clarifying the contractAsk or state assumptions:17.3Basic designSalesforce:17.4codeDataWeaveInput:17.5Why Upsert?Don't do:17.6Error strategyAnd importantly:17.7TestingMUnit:17.8Q&AInterview answerA concise version:•codeScenario 2 — Account and Contacts“A customer request contains an Account and multiple Contacts. How would you load that into Salesforce?”17.9Identify dependencyContacts belong to Account.17.10codeDesignContact transformation:17.11Ask about transactional semanticsWhat if:17.12Q&ABetter interview wording“I'd identify the dependency first: Contacts require the Account relationship, so I wouldn't parallelize those operations blindly. I'd…•Scenario 3 — Customer profile from Salesforce + Billing + Loyalty“Build an API that returns customer information from Salesforce, Billing and Loyalty.”17.13Determine dependenciesDo the three calls depend on each other?17.14Why Scatter-Gather?Because:17.15codeFailure questionInterviewer asks:17.16Avoid giant latencyIf:17.17Q&AInterview answer“I'd treat this as orchestration in a Process API. Assuming Salesforce, Billing and Loyalty all need only the customer ID and are…•Scenario 4 — 500,000 nightly customer updates“Every night we receive 500,000 customer records that need to synchronize to Salesforce.”17.18First questionAsk:17.19ArchitecturePotential design:17.20Why not For Each?Because:17.21External IDs againUse:17.22Partial failuresSuppose:17.23Systemic failure detectionIf:17.24Q&AInterview answer“I'd first determine whether this should really be a full load or incremental sync. For large write volumes I'd use Salesforce Bulk API v2…•Scenario 5 — Salesforce outage during customer onboarding“A critical customer onboarding API writes to Salesforce, but Salesforce may sometimes be unavailable for 30 minutes. What do you do?”17.25First questionAsk:17.26Async designThen:17.27codeWhat to returnThen perhaps:17.28Failure handlingTrack:17.29Q&AInterview answer“If the business doesn't require immediate Salesforce completion, I'd decouple intake from processing with durable messaging. The API…•Scenario 6 — Salesforce events must update another system“Whenever an Account changes in Salesforce, we need to update our internal customer platform within seconds.”17.30Event-driven designQuestions to ask:17.31codeConsumer designEvent:17.32Why both idempotency and versioning?Duplicate:17.33Q&AInterview answer“For a seconds-level Salesforce change requirement I'd prefer an event-driven mechanism such as Change Data Capture rather than aggressive…•Scenario 7 — Mule → Salesforce → Billing → Email“When a customer signs up, create them in Salesforce, register them in Billing, then send a welcome email.”17.34Naive designProblem:17.35First classify critical vs noncriticalAsk:17.36Better architecturePotential hybrid:17.37Compensation/statusIf Salesforce succeeds but Billing fails:17.38Q&AInterview answer“I'd first determine which side effects are part of the transactional business outcome. I wouldn't assume distributed rollback across…•Scenario 8 — Multiple APIs need Salesforce customer data“Mobile, web, support and order systems all need customer data from Salesforce.”17.39Avoid direct couplingBad:17.40System APICreate:17.41Process APIsThen business processes can reuse it:17.42Important nuanceIf there is only one simple consumer:•Scenario 9 — Duplicate Account incidents in production“We're seeing duplicate Accounts in Salesforce. What would you investigate?”17.43Start with identityAsk:17.44Classic causeCode:17.45Another causeTimeout:17.46Q&AInterview answer“I'd first identify whether duplicate prevention is enforced atomically at the Salesforce boundary. I'd look for query-then-create…•Scenario 10 — API works in QA but fails in PROD“Same Mule application works in QA but Salesforce calls fail in production.”17.47Compare environment differencesChecklist:17.48Q&AInterview answer“Because the same artifact works in QA, I'd first compare environmental dependencies before changing code: Salesforce org and schema…•Scenario 11 — API suddenly gets much slower“The Mule customer API went from 500 ms to 5 seconds.”17.49Break latency apartCheck:17.50Avoid the bad answerDon't say:17.51Q&AInterview answer“I'd decompose the latency first. I'd compare end-to-end p95 with Salesforce and other dependency latency, retries, connection saturation…•Scenario 12 — Design a complete production Mule→Salesforce integrationThis is the big one.17.52RequirementAssume:17.53API architectureTransactional path:17.54Mule flow17.55Error handlingStructured logs with:17.56IdempotencySalesforce:17.57Bulk pathNightly sync:17.58SecurityNo secrets in Git/logs.17.59TestingMUnit:17.60DeploymentRuntime config differs.17.61ObservabilityMonitor:17.62The polished full answerThis is worth practicing almost verbatim:17.63Q&AWhat the interviewer may challenge nextAfter your first answer, expect follow-ups like:17.64Q&AWhat not to do in a system-design interviewAvoid immediately diving into syntax:17.65Your senior-language vocabularyThese terms are useful because they describe real engineering decisions:•cheat sheetModule 17 one-screen cheat sheetWhen you get a design question and need five seconds to organize yourself, start with: