Module 17 one-screen cheat sheet

SYSTEM DESIGN ANSWER
====================

1. Contract
2. Sync or async?
3. System boundaries
4. Dependencies
5. DataWeave mapping
6. Salesforce operation
7. Error semantics
8. Idempotency
9. Volume/concurrency
10. Security
11. Testing
12. Deployment
13. Observability


TRANSACTIONAL SF WRITE
======================

HTTP
↓
Validate
↓
DataWeave
↓
Upsert by External ID
↓
Response


LARGE DATA
==========

delta
↓
Mule Batch if needed
↓
Salesforce Bulk API v2


MULTIPLE INDEPENDENT SYSTEMS
============================

Scatter-Gather


DEPENDENT OPERATIONS
====================

sequence them


LONG/OUTAGE-TOLERANT WORK
=========================

queue
↓
202
↓
async consumer


FAILURE
=======

transient
→ maybe retry

permanent
→ don't retry


TIMEOUT
=======

unknown outcome


DUPLICATES
==========

unique External ID
+ Upsert


PARTIAL CROSS-SYSTEM FAILURE
============================

no magical rollback

retry
compensate
reconcile
track state


TESTING
=======

MUnit
+
real Salesforce integration
+
few E2E


PRODUCTION
==========

immutable artifact
secure config
correlation IDs
metrics
alerts

The answer pattern I most want you to memorize

When you get a design question and need five seconds to organize yourself, start with:

“First I'd clarify the contract, volume, latency requirement and whether the caller needs synchronous completion. Then I'd identify the system dependencies and stable business keys, because those determine orchestration, Salesforce operation, idempotency and retry strategy.”

That buys you thinking time and sounds exactly like someone who designs integrations rather than merely knows Mule components.

Module 18 is the final technical module: Interview Coding Scenarios. We'll practice the things they might actually ask you to write or sketch: Mule flow structure, DataWeave transformations, SOQL, Choice logic, Salesforce Upsert, error-handler pseudocode, and a small MUnit test—essentially a compact “write this on screen without looking clueless” drill.