Module 10 — Synchronous vs Asynchronous Integrations
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.1Synchronous integrationClassic request/response:10.2Synchronous exampleA UI asks:10.3The synchronous reliability problemNow imagine:10.4Asynchronous integrationInstead:10.5HTTP 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.24Practical 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.28What 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.34Async Salesforce update exampleMessage:10.35Event 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.49Async success response doesn't mean business completionImportant API semantic.10.50Status 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.57Interview scenarioUser creates a customer and needs the Salesforce ID before continuing.10.58Interview scenarioWe receive 500,000 nightly updates.10.59Interview scenarioSalesforce may be unavailable for an hour, but we must not lose requests.10.60Interview scenarioAccount changes in Salesforce must be propagated within seconds.10.61Interview scenarioEvents sometimes arrive twice.•Module 10 cheat sheetThe interview sentence to memorize is: