Event-Driven Architecture

Event-driven architecture (EDA) decouples systems by communicating through events rather than direct API calls. Salesforce provides multiple event technologies, and choosing the right one is a common CTA differentiator between candidates who pass and those who fail.

---

Why Event-Driven?

Traditional request-response integration creates tight coupling: System A must know about System B, handle its failures, and wait for its response. Event-driven architecture breaks that dependency.

Aspect	Request-Response	Event-Driven
Coupling	Tight - caller knows callee	Loose - publisher does not know subscribers
Availability	Caller blocked if callee is down	Publisher unaffected by subscriber failures
Scalability	Limited by slowest participant	Subscribers scale independently
Latency	Synchronous wait	Asynchronous processing
Complexity	Simple for 1:1	Simple for 1:many
Error handling	Direct (caller gets error)	Indirect (needs monitoring, DLQ)

---

Salesforce Event Technologies Comparison

Feature	Platform Events	Change Data Capture	Streaming API (PushTopic)	Pub/Sub API
Purpose	Custom business events	Data change notifications	SOQL-based change notifications	High-throughput event streaming
Event definition	Custom (you define schema)	Automatic (mirrors object fields)	SOQL query	Subscribes to PE/CDC channels
Publish mechanism	Apex, Flow, API, Process Builder (deprecated)	Automatic on record change	Automatic on record change	gRPC publish
Subscribe mechanism	Apex Trigger, PE-Triggered Flow, API, LWC	Apex Trigger, API, LWC	CometD client	gRPC subscribe
Retention	72 hours (high-volume) / 24 hours (standard)	3 days	No replay storage	Depends on event type
Replay	Yes (replay ID)	Yes (replay ID)	Limited	Yes (managed subscriptions)
Delivery	At-least-once	At-least-once	At-most-once	At-least-once
Status	Active, strategic	Active, strategic	Maintenance mode	Active, strategic
CTA relevance	High	High	Low (legacy)	High

---

Platform Events

Custom-defined events representing business occurrences. You control the schema (fields) and the semantics (what the event means).

When to Use

• Custom business events not tied to a single record change (e.g., OrderSubmitted, PaymentProcessed)
• Decoupling Salesforce from external systems
• Broadcasting events to multiple subscribers
• Triggering flows or processes from external systems

Architecture

Figure 1. Platform Events support multiple publisher types and fan out to multiple independent subscribers. Publishing is independent of the DML transaction by default; use the “Publish After Commit” setting to tie event delivery to transaction success.

Key Characteristics

• Standard volume: 25 events per Apex transaction, 24-hour retention
• High volume: Unlimited publish from Apex, 72-hour retention (requires enablement)
• Publish behavior: EventBus.publish() is independent of the DML transaction. Events publish even if the transaction rolls back (unless using setSavepoint() with platform events)
• Subscribe in Apex: after insert trigger on the event object

Transaction independence

Platform Events publish independently of the DML transaction by default. If you publish an event and then the transaction rolls back, the event is STILL published. Use the Publish After Commit behavior setting on the event definition to tie publishing to transaction success. This is a critical CTA detail.

Standard vs High-Volume Platform Events

Standard-volume deprecation

Standard-volume platform events can no longer be created as of 2025. Existing standard-volume events continue to function, but full retirement is scheduled for Summer ‘27. All new platform event definitions should use high-volume. Plan migration of existing standard-volume events before the retirement date.

Feature	Standard Volume (deprecated)	High Volume
Publish limit per transaction	25	No Apex limit
Retention	24 hours	72 hours
Allocation	Included in org	Requires entitlement
Replay	Yes	Yes
Status	No new creation; retirement Summer ‘27	Active, strategic
Use case	Legacy low-volume business events	All new platform event implementations

---

Change Data Capture (CDC)

Automatically publishes events when records are created, updated, deleted, or undeleted. No custom event definition needed. CDC mirrors the object’s fields.

When to Use

• Synchronizing Salesforce data changes to external systems
• Audit trails for data changes
• Populating data lakes or warehouses in near-real-time
• When you need to know WHAT changed (field-level change tracking)

Architecture

Figure 2. CDC requires zero publish code. The engine automatically fires on any DML operation and includes field-level change tracking in the payload. The 3-day retention window allows subscribers to replay missed events after short outages.

CDC Event Payload

CDC events carry rich change information:

Field	Description
ChangeEventHeader	Change type (CREATE/UPDATE/DELETE/UNDELETE), changed fields, record IDs
changedFields	List of field API names that changed
Record fields	Current values of changed fields
commitTimestamp	When the change was committed
transactionKey	Groups changes from the same transaction

Key Characteristics

• Retention: 3 days
• Objects: Standard and custom objects (select which to enable)
• Enriched events: Includes which fields changed and their new values
• Gap events: Published when CDC detects missed events, prompting subscribers to refresh
• Composite changes: Multiple record changes in one transaction are grouped

CDC vs Platform Events

Decision Factor	Use CDC	Use Platform Events
Need to track data changes	Yes - automatic	No - you would have to build it
Custom event semantics	No - tied to object schema	Yes - you define the meaning
Field-level change tracking	Built-in (changedFields)	Must include manually
Multiple objects	Enable per object	One event definition per use case
External publishing	No (Salesforce only)	Yes (API, external systems)

CDC vs Platform Events: Side-by-Side Architecture

CDC and Platform Events flow through different paths on the same underlying event bus infrastructure.

Figure 3. CDC and Platform Events share the same event bus but serve different purposes: CDC for automatic data-change notifications with field-level tracking, Platform Events for custom business semantics with developer-controlled payloads. High-volume CDC on many objects can consume shared delivery allocations.

They share the same event bus infrastructure

Platform Events and CDC share event bus infrastructure. Delivery allocations are edition-dependent — consult the official Platform Event Allocations documentation for current numbers. In scenarios with high-volume CDC enabled on many objects, budget the shared allocation carefully. A common CTA trap: enabling CDC on too many objects and starving Platform Event delivery.

---

Pub/Sub API (gRPC)

The modern event streaming API replacing the CometD-based Streaming API. Built on gRPC for high-performance bidirectional streaming.

When to Use

• External systems subscribing to high volumes of Platform Events or CDC
• When you need managed subscriptions (server-side cursor tracking)
• When CometD performance is insufficient
• Modern microservices architectures using gRPC

Key Advantages Over Legacy Streaming

Feature	Streaming API (CometD)	Pub/Sub API (gRPC)
Protocol	HTTP long-polling	gRPC (HTTP/2)
Performance	Moderate	High throughput
Subscription management	Client-managed	Server-managed (optional)
Encoding	JSON	Avro (compact binary)
Bidirectional	Subscribe only	Publish and subscribe
Future	Maintenance mode	Strategic direction

Managed Subscriptions

Pub/Sub API supports managed subscriptions where the server tracks the subscriber’s position (replay cursor). If the subscriber disconnects and reconnects, it resumes from where it left off. The client does not need to store replay IDs.

Figure 4. Managed subscriptions eliminate client-side replay ID management. The server tracks position and resumes from the last committed cursor on reconnect. This simplifies subscriber code and prevents event gaps after brief disconnections.

Pub/Sub API gRPC Bidirectional Streaming

The gRPC protocol enables full bidirectional streaming over a single HTTP/2 connection. Client and server operate independently, sending and receiving messages at the same time without blocking. This is fundamentally different from REST polling.

Figure 5. The gRPC protocol multiplexes subscribe and publish flows over a single persistent HTTP/2 connection. Pull-based delivery gives the client back-pressure control, and Avro binary encoding reduces payload size by 7-10x compared to JSON.

gRPC Feature	Benefit for Integration
HTTP/2 multiplexing	Multiple streams over single connection, no connection overhead
Binary Avro encoding	7-10x smaller payloads than JSON, lower bandwidth
Server-side cursor	No client-side replay ID management, simpler code
Pull-based delivery	Client controls pace; back-pressure built in
Bidirectional streams	Publish and subscribe on same connection

CTA board point

When recommending Pub/Sub API over CometD/Streaming API, highlight three things: (1) gRPC is 7-10x faster than REST/CometD, (2) managed subscriptions eliminate client-side replay ID management, and (3) Avro binary encoding reduces payload size significantly. CometD is in maintenance mode - all new implementations should use Pub/Sub API.

---

Event Bus Architecture

All Salesforce event technologies share the same underlying event bus infrastructure.

Figure 6. All Salesforce event technologies share the same underlying event bus. DML operations feed CDC channels automatically; Platform Event channels require explicit publish calls. New implementations should use gRPC (Pub/Sub API) for external subscribers rather than legacy CometD.

---

Replay Mechanism and Retention

Events are stored temporarily on the event bus with a replay ID. Subscribers replay missed events within the retention window.

Event Type	Retention Period	Replay Support
Platform Events (standard volume)	24 hours	Yes (replay ID)
Platform Events (high volume)	72 hours	Yes (replay ID)
Change Data Capture	3 days	Yes (replay ID)
Generic Streaming (legacy)	None	No

Replay Positions

Position	Behavior
-1 (LATEST)	Only receive new events from now
-2 (EARLIEST)	Replay all events from beginning of retention window
Specific replay ID	Resume from a specific point

The 24-hour/72-hour trap

If your subscriber is down longer than the retention period, those events are gone. Always design for this: What is the recovery strategy when the subscriber misses events beyond the retention window? Options: full data reconciliation job, alerting when subscriber lag exceeds a threshold, or a hybrid approach combining CDC with periodic batch sync.

---

Event-Driven Decision Flowchart

Figure 7. Event technology selection depends on what triggers the event, whether field-level change tracking is needed, and the subscriber’s performance requirements. External high-throughput subscribers should always use Pub/Sub API gRPC rather than the legacy CometD protocol.

---

Outbound Messages vs Platform Events

Both Outbound Messages and Platform Events deliver asynchronous notifications from Salesforce to external systems, but they use very different architectures. Picking the wrong one creates unnecessary complexity or limits scalability.

Comparison

Factor	Outbound Messages	Platform Events
Protocol	SOAP (WSDL-based)	REST, gRPC (Pub/Sub API), CometD
Trigger	Workflow Rules (end of support Dec 2025) or Flow actions	Apex, Flow, REST API, external gRPC publish
Delivery model	Push to a specific SOAP endpoint	Pub/Sub - publish to bus, subscribers pull
Retry	Built-in: retries for 24 hours (extendable to 7 days) until positive ACK	At-least-once delivery; no automatic endpoint retry (subscriber manages replay)
Idempotency	Unique message ID preserved across retries	Replay ID for subscriber-side deduplication
Subscriber count	Single endpoint per outbound message	Multiple independent subscribers
Payload	Up to 100 field values from the triggering record + Session ID	Custom schema you define (any fields)
Retention	Queued until ACK or expiry (24h/7d)	72 hours (high-volume) / 24 hours (standard)
Volume	Low-moderate (queued delivery)	High (high-volume PE: no Apex transaction limit)
Status	Active but legacy-adjacent	Strategic, actively enhanced

Decision Guide

Scenario	Recommendation	Rationale
Simple notification to a single SOAP endpoint	Outbound Message	Built-in retry, zero code, WSDL contract
Multiple subscribers need the same event	Platform Events	Pub/Sub model supports multiple independent subscribers
High-volume or burst notifications	Platform Events	High-volume PE has no per-transaction publish limit
External system publishes events into Salesforce	Platform Events	Outbound Messages are Salesforce-to-external only
Need to include custom/computed data in the payload	Platform Events	Outbound Messages are limited to record field values
Legacy SOAP integration with existing WSDL consumer	Outbound Message	Avoids rework if consumer already handles the WSDL
Event-driven architecture with replay and monitoring	Platform Events	Replay IDs, Pub/Sub API managed subscriptions, event monitoring

CTA Exam Relevance

The board sometimes presents a scenario where an admin configured Outbound Messages for a notification pattern that now needs to scale to multiple consumers or higher volume. The correct answer is to migrate to Platform Events, but acknowledge the trade-off: you lose built-in endpoint retry (the subscriber must manage replay/redelivery) and must build idempotent consumers. When the scenario describes a simple, single-endpoint SOAP notification with no scaling concerns, Outbound Messages remain a valid and simpler choice.

---

Anti-Patterns

Anti-Pattern	Why It Fails	Better Approach
Using events for guaranteed delivery	At-least-once is not exactly-once	Design idempotent consumers, add reconciliation
Ignoring replay window	Events lost after retention expires	Monitor subscriber lag, batch sync fallback
Polling instead of subscribing	Wastes API calls, higher latency	Subscribe via Pub/Sub API or CDC
Publishing events on transaction rollback	Creates phantom events	Use “Publish After Commit” behavior
Single subscriber bottleneck	One slow subscriber blocks processing	Scale subscribers independently, use DLQ

---

Related Topics

• Data Quality & Governance: CDC event subscribers must handle data quality issues (missing fields, invalid formats) gracefully
• Modern Platform Features: Platform Events and CDC are foundational to Agentforce, Flow orchestration, and modern event-driven platform capabilities
• Sharing Model: event subscribers run in system context; sharing rules still apply to data accessed by event handlers

---

Sources

• Platform Events Developer Guide
• Change Data Capture Developer Guide
• Pub/Sub API Developer Guide
• Pub/Sub API gRPC Architecture
• Pub/Sub API Bidirectional Streaming
• Pub/Sub API Managed Subscriptions
• Trailhead: Platform Events
• Salesforce Architect: Event-Driven Architecture
• Streaming API Developer Guide
• Outbound Message Considerations (Salesforce Help)
• Understanding Outbound Messaging (SOAP API Developer Guide)