Module 10 — Synchronous vs Asynchronous Integrations
This module is about a core architecture decision:
Does the caller wait for the work to finish, or do we accept the work and finish it later?
That choice affects latency, reliability, retries, user experience, error handling, and scaling.
10.1codeSynchronous integrationClassic request/response:10.2Synchronous exampleA UI asks:10.3The synchronous reliability problemNow imagine:10.4Asynchronous integrationInstead:10.5codeHTTP 202A common async response is:10.6Why async is more resilientSuppose Salesforce is unavailable for 20 minutes.10.7Queue as a shock absorberSuppose normal traffic:10.8But queues don't create capacityIf requests arrive at:10.9Mule async optionsDepending on environment, you'll encounter things like:10.10Queue mental modelProducer:10.11Queue vs Flow ReferenceFrom Module 6:10.12Async Scope vs messagingYou may also hear Mule's:10.13Event-driven architectureInstead of commanding:10.14Command vs eventUseful distinction:10.15ChoreographyRemember Module 6?10.16Eventual consistencyThis is one of the biggest async concepts.10.17Eventual consistency isn't necessarily a bugFor many integrations:10.18PollingAnother common pattern:10.19Event vs pollingSuppose Salesforce changes Account.10.20Salesforce Change Data CaptureSalesforce CDC is conceptually:10.21Platform EventsPlatform Events are more business-event-oriented.10.22Pub/Sub APIYou may hear Salesforce:10.23At-most-once, at-least-once, exactly-onceThis terminology often appears in messaging interviews.10.24codePractical integration mindsetMost real message systems often force you to reason as if:10.25Why duplicate events happenConsumer receives:10.26Therefore acknowledge only after successConceptually:10.27Dead Letter QueueAfter repeated failures:10.28codeWhat belongs in DLQ?Example:10.29Retry queue vs DLQA mature architecture may have:10.30Poison messageA message that will never succeed without correction:10.31OrderingSuppose events arrive:10.32Key-based orderingIf broker supports partitioning/keying, you might use:10.33Idempotency alone doesn't solve stale orderingImportant nuance.10.34codeAsync Salesforce update exampleMessage:10.35codeEvent schema versioningEvents themselves are contracts.10.36Sync vs async decision ruleAsk:10.37Good synchronous use caseswhere response is immediately needed.10.38Good asynchronous use cases10.39Hybrid patternVery common:10.40Another hybridThen:10.41Scheduler patternMule Scheduler can trigger flows:10.42Scheduler + watermarkTypical delta sync:10.43Polling too frequentlyBad:10.44Polling too infrequentlyIf requirement says:10.45Event replaySuppose consumer is down for an hour.10.46Async observabilitySynchronous:10.47Queue depthSuppose:10.48Oldest message ageEven more useful sometimes:10.49codeAsync success response doesn't mean business completionImportant API semantic.10.50codeStatus resourceA robust async API might return:10.51Callback/webhook patternInstead of polling status:10.52Exactly-once delivery — be skepticalIf interviewer says:10.53Exactly-once business effectExample:10.54Transaction boundary with queueA hard problem:10.55Outbox pattern mental modelInstead of:10.56Salesforce as source vs targetSo far we've mostly had:10.57Q&AInterview scenarioUser creates a customer and needs the Salesforce ID before continuing.10.58Q&AInterview scenarioWe receive 500,000 nightly updates.10.59Q&AInterview scenarioSalesforce may be unavailable for an hour, but we must not lose requests.10.60Q&AInterview scenarioAccount changes in Salesforce must be propagated within seconds.10.61Q&AInterview scenarioEvents sometimes arrive twice.•cheat sheetModule 10 cheat sheetThe interview sentence to memorize is: