Event-driven architecture

The most scalable modern integrations avoid point-to-point coupling entirely. In an event-driven architecture (EDA), systems communicate by publishing and reacting to events on a shared bus, so a producer never needs to know who its consumers are. Salesforce is a first-class participant through its event bus, and an architect reaches for EDA when they need real-time, decoupled, many-to-many communication that can evolve without rewiring every integration.

Salesforce offers several event mechanisms. Platform Events are custom-defined messages (API name __e) that any system can publish and multiple subscribers can consume — the general-purpose tool for business events like "Order Placed". Change Data Capture (CDC) automatically publishes events whenever records of a selected object change, so external systems can keep their copies in sync in near-real time without polling. Both flow over the same streaming event bus, which retains events for replay and lets subscribers catch up after downtime using a replay id.

Producer                 Event Bus                 Subscribers
--------                 ---------                 -----------
Salesforce  --publish--> [ Order_Placed__e ] --+--> Fulfilment service
ERP         --publish-->                       +--> Analytics pipeline
                                               +--> Notification LWC (empApi)

Change Data Capture: Account/Contact/etc. changes -> auto-published -> external sync

The architectural benefits are loose coupling (add or remove subscribers without touching the producer), scalability (the bus absorbs spikes and delivers asynchronously), and resilience (retained, replayable events survive a subscriber outage). Choose Platform Events for explicit business events you model yourself, and CDC when the requirement is simply "keep another system's data in sync with Salesforce records."

The trade-offs are real: events are asynchronous and eventually consistent, delivery and ordering guarantees differ from a database transaction, and there are per-org publishing and delivery limits to design within. EDA is superb for notifications and sync, and the wrong tool when you need a synchronous, transactional answer — for that, use request-reply.

As an exercise, take a landscape of three systems that all care about "customer updated" and design it two ways — point-to-point versus event bus — and articulate why the event-driven version scales better as a fourth and fifth system appear. Completing this lesson finishes the architect roadmap: you now reason about data, sharing, and integration at scale, the core of the architect mindset.