Module 9 cheat sheet

SYSTEM API
==========
backend abstraction

Salesforce
SAP
database
billing

owns:
connector
authentication
SOQL
backend schema mapping
backend error normalization


PROCESS API
===========
business orchestration

combines systems
owns business rules
handles workflow


EXPERIENCE API
==============
consumer adaptation

mobile
web
partner
call center


CLASSIC MODEL
=============

Experience
    ↓
Process
    ↓
System
    ↓
backend


BUT:
not every use case needs 3 hops.


GOOD ARCHITECTURE
=================

Salesforce details stay
inside Salesforce System API

Business rules stay
inside Process API

Consumer-specific formatting stays
inside Experience API


MAIN GOAL
=========

reuse
decoupling
stable contracts
governance


MAIN RISK
=========

too many layers
latency
distributed monolith
unnecessary operational complexity

The one sentence to remember:

“System APIs hide backend details, Process APIs own business orchestration, and Experience APIs adapt capabilities to consumers—but I wouldn't create all three layers unless the separation creates real value.”

Next is Module 10: synchronous vs asynchronous integrations—HTTP request/response, schedulers, queues, event-driven flows, Salesforce Platform Events/CDC, polling, retries, DLQs, eventual consistency, and how to decide whether an integration should respond immediately or finish later.