Module 12 Cheat Sheet

IDEMPOTENCY
===========

same logical request repeated
→ no unintended additional effect


SALESFORCE
==========

best common pattern:

stable External ID
+
unique constraint
+
Upsert


DON'T DO
========

Query
→ not found
→ Create

under concurrency


BUSINESS KEY
============

identifies entity

customerId
orderId


IDEMPOTENCY KEY
===============

identifies operation

requestId
paymentId
eventId


ATOMICITY
=========

check-then-act can race

prefer:
unique constraint
atomic claim
downstream-native idempotency


DUPLICATE EVENTS
================

normal under at-least-once delivery


ORDERING
========

idempotency ≠ ordering

use:
version
sequence
timestamp/optimistic concurrency


RETRIES
=======

timeout = unknown outcome

retry only when business effect is safe


WORKFLOW
========

every side effect must be considered

Salesforce upsert may be idempotent
email/publish/payment may not be

The interview sentence to memorize is:

“I try to enforce idempotency at the actual side-effect boundary using stable business keys and atomic uniqueness—for Salesforce that often means a unique External ID plus Upsert. I don't rely on query-then-create because it races under concurrency, and I treat ordering/versioning as a separate problem from duplicate suppression.”

Next is Module 13: MUnit — this should be particularly useful for you because it connects directly to your automation background: how Mule unit tests are structured, mock-when, verify-call, assertions, event setup, testing Choice branches, testing error handlers, and deciding what should be mocked versus tested against a real Salesforce sandbox.