Module 10 cheat sheet

SYNCHRONOUS
===========
caller waits
immediate final response

good for:
quick reads
small transactions
immediate decisions


ASYNCHRONOUS
============
caller doesn't wait for completion

often:
publish queue/event
return 202

good for:
long work
large volume
retries
downstream outages
traffic spikes


QUEUE
=====
buffer
load leveling
temporal decoupling


EVENTUAL CONSISTENCY
====================
systems may temporarily differ
but converge later


POLLING
=======
Scheduler
+ watermark
+ changed records


EVENT-DRIVEN
============
CDC
Platform Events
Pub/Sub


DELIVERY
========

at-most-once
at-least-once
exactly-once

practical assumption:
duplicates may happen


IDEMPOTENCY
===========
duplicate delivery
must not create duplicate business effects


ORDERING
========
duplicates and ordering are separate problems

use:
versions
sequence
partition/key where appropriate


RETRIES
=======
bounded

transient failures only


DLQ
===
messages that automatic processing
could not successfully complete


OBSERVABILITY
=============

correlationId
eventId
retry count
queue depth
oldest message age
DLQ count

The interview sentence to memorize is:

“I choose synchronous processing when the caller genuinely needs the final result immediately. For long-running, high-volume, or outage-tolerant workflows I prefer durable asynchronous messaging, and I design consumers assuming duplicate delivery is possible—so idempotency, ordering, retries, replay, and DLQ handling are part of the design.”

Next, Module 11 should be Salesforce Bulk processing and Mule Batch Jobs: when to use ordinary connector operations versus Bulk API v2, chunking, job lifecycle, partial failures, batch aggregation, and designing a 100k–1M-record synchronization without destroying memory or Salesforce API limits.