Module 11 Cheat Sheet

NORMAL CRUD
===========
small / transactional
interactive
immediate response


SALESFORCE BULK API
===================
large data volume
job-based
asynchronous

Bulk v2:
insert
update
upsert
delete
query


MULE BATCH
==========
large record processing

Batch Job
   ↓
Batch Step
   ↓
Batch Step
   ↓
On Complete


BATCH AGGREGATOR
================
records
↓
group into arrays
↓
bulk-capable downstream call


FAILURES
========
record-level failure isolation

maxFailedRecords

don't retry permanent errors


IDEMPOTENCY
===========
external IDs
upsert

critical for replay/restart


PERFORMANCE
===========
avoid N+1

stream/page data

don't load millions
into one in-memory array

respect Salesforce
concurrency and locking


SYNCHRONIZATION
===============
prefer delta loads

watermarks / CDC

handle deletes

periodic reconciliation

The interview sentence to memorize is:

“For high-volume Salesforce synchronization I'd separate Mule's batch-processing responsibility from Salesforce's Bulk API responsibility: Mule Batch can manage record-level processing, failures, aggregation, and restartability, while Bulk API v2 handles the high-volume Salesforce operation itself. I'd design the whole pipeline around external IDs, incremental loads, streaming, partial-failure recovery, and reconciliation.”

That is a very credible developer answer.

Next is Module 12: Idempotency and duplicate prevention. We've referenced it constantly, but now we should make it concrete: idempotency keys, Salesforce external IDs, duplicate event handling, race conditions, request replay, Object Store/database-based deduplication, versioning, and what happens when two Mule workers process the same customer simultaneously.