Events vs APIs, Scalability, Reliability & Architecture Decision Framework
Modern Salesforce architectures rarely operate in isolation.
A Salesforce org may need to exchange information with ERP systems, data platforms, customer portals, integration platforms, downstream applications, analytics platforms, AI agents, and other Salesforce orgs. The architectural question is therefore not simply “How do we integrate Salesforce?”
The more important question is:
Should this interaction be modeled as an API call, an event, or a combination of both?
That distinction becomes increasingly important as enterprise Salesforce landscapes grow.
APIs are generally designed around request and response.
Events are designed around something that happened.
Salesforce provides several mechanisms for implementing event-driven architectures, including:
- Platform Events
- Change Data Capture (CDC)
- Pub/Sub API
- Platform Event-triggered automation
- Event-driven integration through middleware
- Combinations of APIs and events
The challenge for an architect is not learning what each feature does.
The challenge is determining which interaction should use which mechanism, where events should originate, who should consume them, how failures should be handled, and how the architecture should scale.
This article provides an architecture-focused framework for making those decisions.
1. The Fundamental Shift: From Request-Driven to Event-Driven Architecture
Traditional integration architectures tend to be request-driven.
An application needs information, so it calls another system.
For example:
Salesforce
|
| GET Customer
v
Integration Layer
|
v
ERP
The calling application knows:
- who it is calling
- what operation it wants
- when it wants it
- what response it expects
This creates relatively tight temporal coupling.
Event-driven architecture changes the interaction model.
Instead of asking another system to do something, Salesforce can publish the fact that something happened.
Salesforce
|
| CustomerCreated
v
Event Bus
|
+----> ERP
|
+----> Data Platform
|
+----> Customer 360
|
+----> AI Platform
|
+----> Notification Service
Salesforce does not necessarily need to know which applications consume the event.
That creates a fundamentally different architecture.
2. API vs Event: The Most Important Architectural Distinction
The simplest distinction is:
API: “I want you to do something.”
Event: “Something happened.”
Consider a customer onboarding process.
An API interaction might look like:
Salesforce -> ERP
Create Customer
Salesforce explicitly requests the ERP to create the customer.
An event-driven interaction might look like:
Salesforce -> CustomerCreated Event
|
+--> ERP
+--> Marketing
+--> Data Lake
+--> Analytics
+--> Customer 360
The event represents a business fact.
The consumers decide what to do with that fact.
This difference has significant architectural consequences.
3. APIs Are Still Essential
Event-driven architecture does not mean replacing APIs with events.
That is one of the most common architectural misunderstandings.
APIs remain appropriate when:
- the caller needs an immediate response
- the operation is synchronous
- a specific system owns the requested operation
- the caller needs validation before proceeding
- the interaction is command-oriented
- the consumer must confirm success
- the caller needs specific data at a particular point in time
For example:
Salesforce
|
| Get Account Credit Limit
v
Credit Service
|
| $250,000
v
Salesforce
An event would not necessarily be appropriate here because Salesforce is explicitly requesting information.
4. When Events Become More Valuable
Events become particularly valuable when the architecture needs:
- loose coupling
- asynchronous processing
- multiple consumers
- scalability
- independent consumer lifecycles
- near-real-time propagation
- workload buffering
- integration decoupling
- eventual consistency
Consider an Order Accepted event.
Instead of Salesforce invoking five systems:
Salesforce
|
+--> ERP
|
+--> Billing
|
+--> Warehouse
|
+--> Data Lake
|
+--> Notification
Salesforce can publish:
OrderAccepted
The event infrastructure then distributes the business fact to interested consumers.
This changes the dependency model.
5. The Architecture Problem: Coupling
The real benefit of event-driven architecture is not simply asynchronous processing.
It is decoupling.
Consider a tightly coupled architecture:
Salesforce
|
+--> ERP
+--> Billing
+--> Warehouse
+--> Marketing
Salesforce becomes aware of multiple downstream systems.
Now consider:
Event Bus
|
OrderAccepted
|
+--------+--------+
| | |
ERP Billing Warehouse
Salesforce publishes one event.
Consumers independently subscribe.
This creates a producer-consumer decoupling boundary.
That boundary becomes increasingly valuable as enterprise landscapes grow.
6. Salesforce Platform Events
Platform Events are designed to represent business events that Salesforce or external systems can publish and consume.
Examples include:
- CustomerCreated
- OrderSubmitted
- PaymentReceived
- ContractApproved
- CaseEscalated
- PolicyIssued
- ShipmentDispatched
A Platform Event can be modeled around a business fact.
For example:
OrderSubmitted__e
OrderId
CustomerId
OrderNumber
OrderValue
Currency
SubmittedBy
SubmittedAt
The event becomes a contract between the producer and consumers.
7. Platform Events Should Represent Business Events
A common mistake is designing events around technical operations.
Poor event:
UpdateAccountRecord
Better:
AccountCreditStatusChanged
Poor:
OpportunityTriggerExecuted
Better:
OpportunityWon
The second approach creates a more meaningful event contract.
The event should communicate:
What happened in the business?
rather than:
What Salesforce implementation detail occurred?
This distinction becomes critical when events are consumed outside Salesforce.
8. Change Data Capture Is Different
CDC solves a different problem.
Platform Events are generally business-defined events.
CDC is primarily about data change notification.
For example:
Account
|
| Record changed
v
CDC Event
The CDC event communicates that a Salesforce record changed.
This makes CDC particularly useful for:
- data synchronization
- downstream replication
- data lakes
- analytics
- search indexes
- integration platforms
- external system synchronization
The architectural question is therefore:
Do consumers need to know that a business event occurred, or that data changed?
That distinction often determines Platform Events vs CDC.
9. Platform Events vs CDC
A useful mental model is:
| Requirement | Platform Events | CDC |
|---|---|---|
| Business event | Excellent | Not primary purpose |
| Record change notification | Possible | Excellent |
| Data replication | Possible | Excellent |
| Business process trigger | Excellent | Less suitable |
| Explicit event schema | Excellent | Salesforce-generated |
| Multiple downstream consumers | Excellent | Excellent |
| Domain event modeling | Excellent | Limited |
| Synchronization | Possible | Excellent |
Consider:
Opportunity Amount Changed
If an external data platform needs the updated Salesforce record, CDC may be the natural choice.
But if the business wants:
OpportunityWon
to trigger downstream processes, a Platform Event is generally a better architectural abstraction.
10. Pub/Sub API: The Distribution Layer
Salesforce Pub/Sub API provides a modern mechanism for publishing and consuming event streams, including Platform Events and CDC events.
Architecturally, it is important to distinguish:
Event type from API used to access the event stream.
Platform Events and CDC describe what is being published.
Pub/Sub API provides a way for external applications to interact with those event streams.
Conceptually:
Salesforce Event Stream
|
v
Pub/Sub API
|
+----+----+
| |
Consumer A Consumer B
This distinction matters when designing enterprise integration platforms.
11. The Three Concepts Should Not Be Treated as Competitors
A common architectural mistake is asking:
“Should we use Platform Events, CDC, or Pub/Sub API?”
They do not represent three equivalent choices.
A better model is:
Salesforce
|
+----------+----------+
| |
Platform Events CDC
| |
+----------+----------+
|
Event Infrastructure
|
Pub/Sub API
|
External Consumers
Platform Events and CDC represent different event sources.
Pub/Sub API provides an interface for consuming/publishing supported Salesforce event streams.
12. Event-Driven Architecture Is About Flow, Not Just Events
A mature event-driven architecture should be viewed as a lifecycle:
Business Action
|
v
Event Produced
|
v
Event Transport
|
v
Event Consumption
|
v
Processing
|
v
Downstream Action
|
v
Acknowledgement / Monitoring
Each stage introduces architectural concerns.
For example:
Producer
Who owns the event?
Contract
What does the event mean?
Transport
How is it delivered?
Consumer
Who subscribes?
Processing
What happens after receipt?
Failure
What happens when processing fails?
Replay
Can the consumer recover?
Observability
How do we know the event was processed?
13. Scalability: Why Events Can Change the Architecture
Suppose Salesforce has 20 downstream consumers.
A synchronous architecture might create:
Salesforce
|
+--> System 1
+--> System 2
+--> System 3
...
+--> System 20
Every additional consumer potentially increases coupling and operational complexity.
An event-driven architecture can instead look like:
Event Bus
|
+----------------+----------------+
| | | | |
S1 S2 S3 S4 S20
The producer publishes once.
Consumers scale independently.
This is particularly valuable when consumers have different:
- processing speeds
- availability
- deployment schedules
- scaling requirements
- technology stacks
14. But Events Do Not Automatically Make a System Scalable
This is an important architectural caveat.
Simply introducing Platform Events does not guarantee scalability.
You can still create bottlenecks through:
- poorly designed event payloads
- excessive event volume
- synchronous downstream processing
- inefficient consumers
- shared databases
- uncontrolled retries
- duplicate processing
- inadequate monitoring
- poor partitioning
- downstream API limits
Therefore:
Event-driven architecture moves scalability problems; it does not eliminate them.
The architecture must consider the entire event lifecycle.
15. Backpressure and Consumer Independence
One of the strongest advantages of asynchronous architectures is the ability to decouple producer speed from consumer processing speed.
Imagine Salesforce produces:
10,000 events/minute
while a downstream system can process:
2,000 events/minute
A synchronous design can quickly become problematic.
An asynchronous architecture can introduce buffering and independent consumer processing.
Conceptually:
Producer
|
| 10,000/min
v
Event Infrastructure
|
| buffering
v
Consumer
|
| 2,000/min
The consumer can catch up without forcing the producer to wait for every downstream operation.
The exact limits and delivery behavior must still be validated against the Salesforce capabilities and architecture being implemented.
16. Eventual Consistency Is a Design Choice
Events introduce another architectural characteristic:
eventual consistency.
Consider:
Salesforce
|
| CustomerCreated
v
ERP
The ERP may receive the event milliseconds or seconds after the Salesforce transaction.
Therefore:
Salesforce state = updated
ERP state = catching up
For some business processes, this is perfectly acceptable.
For others, it is not.
Architects must explicitly determine:
How much consistency delay can the business tolerate?
17. Do Not Use Events When Immediate Consistency Is Required
Suppose a user is attempting to complete a transaction and Salesforce must immediately know whether an external credit service approved the transaction.
This is generally an API-style interaction:
Salesforce
|
| Credit Check
v
Credit Service
|
| Approved
v
Salesforce
An event-based interaction could introduce uncertainty about when the response arrives.
Therefore:
Real-time decision → API
Notification of something that happened → Event
This is not an absolute rule, but it is a powerful architectural starting point.
18. The Hybrid Architecture Is Often the Best Architecture
Enterprise systems rarely need to choose exclusively between APIs and events.
A mature architecture often combines them.
For example:
Salesforce
/ \
/ \
API Request Event
| |
v v
Real-time Event Infrastructure
decision |
+--> ERP
+--> Analytics
+--> Notifications
The API handles the immediate decision.
The event handles downstream propagation.
This is often the most practical enterprise pattern.
19. Command vs Event
Another powerful architectural distinction is:
Command
“Please perform this action.”
Event
“This action has occurred.”
For example:
CreateCustomer
is a command.
CustomerCreated
is an event.
Commands usually have a specific target.
Events can have multiple interested consumers.
This distinction prevents many poorly designed event contracts.
20. Event Ownership
Every enterprise event should have a clear owner.
For example:
CustomerCreated
Who owns the definition?
Possibilities include:
- Salesforce
- Customer Master
- MDM platform
- CRM domain
- Integration layer
The event should generally originate from the system that owns the business fact.
If Salesforce is merely replicating another system’s data, it may not be appropriate for Salesforce to declare itself the source of truth.
21. Avoid Turning Salesforce into an Enterprise Event Broker
Another common architectural anti-pattern is:
Every enterprise system
|
v
Salesforce
|
v
Platform Events
|
v
Entire Enterprise
Salesforce should not automatically become the enterprise-wide event backbone.
The correct architecture depends on enterprise integration strategy.
A large organization may use:
Systems of Record
|
v
Enterprise Event Platform
|
+--> Salesforce
+--> ERP
+--> Data Platform
+--> Digital Channels
Salesforce events can participate in this ecosystem without becoming the universal event broker.
22. Event Contract Design
A well-designed event contract should answer:
- What happened?
- Which business entity was affected?
- Which identifier identifies it?
- When did it happen?
- Who or what caused it?
- What information does the consumer need?
- What version of the contract is being used?
For example:
CustomerCreated
eventId
customerId
customerType
sourceSystem
occurredAt
correlationId
eventVersion
The payload should contain enough information for consumers to process the event without unnecessarily coupling them to Salesforce internals.
23. Avoid Overloading Events
An event should not become a dumping ground for every field available on the Salesforce object.
Bad design:
CustomerCreated
+ 200 Salesforce fields
+ UI fields
+ internal metadata
+ unrelated fields
This creates:
- large payloads
- unnecessary coupling
- difficult versioning
- increased data exposure
- harder consumer maintenance
Instead, design the event around consumer needs and business semantics.
24. Event Idempotency
Event consumers must assume that duplicate processing can occur unless the architecture guarantees otherwise.
For example:
OrderAccepted
could potentially be delivered or retried more than once.
A consumer should therefore be designed so that processing the same event twice does not create an incorrect business outcome.
A common pattern is:
eventId
|
v
Processed Event Store
|
+--> Already processed? --> Ignore
|
+--> New? --> Process
Idempotency is one of the most important principles in production event-driven systems.
25. Correlation and Traceability
Distributed event architectures make troubleshooting more difficult.
Consider:
Salesforce
|
v
Event
|
v
MuleSoft
|
v
ERP
|
v
Data Platform
If a business transaction fails, architects need to trace the entire chain.
Events should therefore support correlation concepts such as:
correlationId
eventId
causationId
sourceSystem
occurredAt
These identifiers become extremely valuable for:
- debugging
- monitoring
- audit
- support
- distributed tracing
26. Error Handling Must Be Designed Up Front
A synchronous API failure is relatively straightforward:
Request
|
v
Error Response
Event processing is different.
The producer may have successfully published the event while a consumer fails later.
Therefore:
Producer Success
|
v
Event Published
|
v
Consumer Failure
The producer cannot simply return an error to the original user.
The architecture needs mechanisms for:
- retries
- dead-letter handling
- error queues
- replay
- alerting
- operational dashboards
- remediation
27. Events and Transaction Boundaries
Architects must carefully consider when an event is published relative to the Salesforce transaction.
A business transaction may look like:
Save Salesforce Record
|
v
Publish Event
|
v
Commit
The architectural question is:
What should happen if the transaction fails?
Similarly:
What should consumers assume about the state of the Salesforce record when they receive the event?
These details matter when designing reliable event-driven integrations.
28. Event Ordering
Some business processes care about ordering.
For example:
OrderCreated
OrderApproved
OrderShipped
OrderDelivered
A consumer may need to process these events in the correct logical sequence.
Architects should therefore explicitly assess:
- ordering requirements
- concurrency
- retries
- duplicate delivery
- out-of-order processing
- consumer state management
Never assume that an event architecture automatically guarantees the business ordering semantics you need.
29. Replay and Recovery
A mature event architecture must answer:
What happens if a consumer is unavailable for several hours?
A good event architecture should provide a recovery strategy appropriate to the event technology and retention model.
For example:
Event Stream
|
+---- Consumer A
|
+---- Consumer B
|
X failure
|
Recovery
|
v
Replay
Replay capability can dramatically reduce operational risk.
But replay introduces another requirement:
Consumers must be designed to safely process historical events.
30. API vs Event Decision Matrix
Architects can use the following decision framework.
| Question | Prefer API | Prefer Event |
|---|---|---|
| Need immediate response? | Yes | No |
| Need synchronous validation? | Yes | No |
| Multiple consumers? | Possible | Strong fit |
| Loose coupling? | Limited | Strong fit |
| Business fact notification? | Limited | Strong fit |
| Data synchronization? | Possible | CDC often better |
| Real-time decision? | Strong fit | Usually not |
| Asynchronous processing? | Possible | Strong fit |
| Consumer independence? | Limited | Strong fit |
| Event replay required? | No | Strong fit |
| Request/response semantics? | Strong fit | Poor fit |
| Eventual consistency acceptable? | Not required | Usually required |
This should be treated as a decision aid rather than a rigid rule.
31. A Practical Salesforce Architecture
A mature Salesforce enterprise architecture might look like:
Salesforce
|
+-----------+-----------+
| |
APIs Events
| |
v v
Integration Layer Event Infrastructure
| |
+----+----+ +-------+-------+
| | | | |
ERP Legacy ERP Data AI
Systems Platform
APIs support synchronous interactions.
Events support asynchronous propagation.
CDC supports data-change scenarios.
Pub/Sub API enables external applications to interact with supported Salesforce event streams.
Together they create a more flexible integration architecture.
32. Anti-Pattern: Everything Becomes an Event
One of the biggest mistakes is believing:
“We are adopting event-driven architecture, so every integration should become an event.”
That is incorrect.
For example:
Get Customer Balance
is naturally request-driven.
Turning it into an event can make the architecture unnecessarily complicated.
Similarly:
Validate Address Before Saving
is usually better suited to a synchronous interaction.
Architecture should follow business interaction semantics.
33. Anti-Pattern: Everything Becomes an API
The opposite mistake is equally problematic.
Imagine Salesforce calling ten downstream systems whenever an opportunity closes.
Opportunity Closed
|
+--> API
+--> API
+--> API
+--> API
+--> API
Now Salesforce is coupled to every downstream dependency.
A business event can provide a cleaner architecture:
OpportunityWon
|
v
Event Infrastructure
|
+----+----+----+----+
| | | | |
ERP BI Mktg Data AI
34. Anti-Pattern: Technical Events Instead of Business Events
Avoid events such as:
AccountUpdated
RecordSaved
TriggerCompleted
FlowExecuted
when the consumer actually cares about a business outcome.
Prefer:
CustomerCreditLimitChanged
CustomerOnboarded
OpportunityWon
ContractActivated
Business semantics survive implementation changes better than technical semantics.
35. Anti-Pattern: Consumers Query Salesforce for Everything
A common event architecture mistake is:
Salesforce
|
| CustomerCreated
v
Consumer
|
| GET Customer
v
Salesforce
If every event causes a consumer to immediately call Salesforce for the complete record, the architecture can lose many benefits of event-driven processing.
This creates:
- additional API traffic
- coupling
- latency
- dependency on Salesforce availability
- potential API limit pressure
The event should contain enough information for the intended processing where appropriate.
36. When Should You Choose CDC?
CDC is particularly attractive when the requirement sounds like:
“Tell me whenever this Salesforce data changes.”
Examples:
Account changes
Contact changes
Opportunity changes
Case changes
Typical consumers include:
- data warehouses
- data lakes
- search indexes
- external master data platforms
- analytics platforms
- synchronization services
CDC is therefore often a data propagation pattern, not a business-process event pattern.
37. When Should You Choose Platform Events?
Platform Events are a strong fit when the requirement sounds like:
“Tell interested systems that this business event occurred.”
Examples:
CustomerOnboarded
OrderSubmitted
ContractApproved
PaymentReceived
CaseEscalated
The key is business semantics.
38. When Should You Choose APIs?
Use APIs when the requirement sounds like:
“I need an answer or action from this system now.”
Examples:
Get Credit Limit
Calculate Shipping Cost
Validate Address
Create Payment
Retrieve Customer Profile
These are command/query interactions.
39. The Architect’s Decision Tree
A practical decision process can be:
Start
|
Does caller need immediate
response/decision?
/ \
Yes No
| |
API Is this a business
event/fact?
/ \
Yes No
| |
Platform Event Is this
Salesforce
data change?
/ \
Yes No
| |
CDC Re-evaluate
architecture
Then ask:
Are there many consumers?
|
Yes
|
Can consumers operate independently?
|
Yes
|
Event-driven architecture becomes stronger candidate
40. The Enterprise Architect’s Rule of Thumb
A useful rule is:
Use APIs for intent. Use events for facts. Use CDC for data changes. Use Pub/Sub API to interact with Salesforce event streams externally.
This single distinction can simplify many Salesforce integration decisions.
But enterprise architecture requires going further.
The architect must also evaluate:
- transaction boundaries
- scalability
- latency
- consistency
- ordering
- failure handling
- replay
- observability
- security
- governance
- ownership
- data volume
- consumer independence
41. Reference Architecture
A scalable Salesforce event-driven architecture can be represented as:
Salesforce
|
+--------------+--------------+
| |
Business Events Data Changes
| |
Platform Events CDC
| |
+--------------+--------------+
|
Event Access
|
Pub/Sub API
|
Integration / Event Layer
|
+------------------+------------------+
| | |
ERP Data Platform AI
| | |
Process Analytics Agents
For larger enterprises, an external event platform may sit between Salesforce and downstream systems depending on organizational architecture and integration requirements.
42. Designing for Scale
Scalability should be evaluated at multiple levels.
Salesforce producer scalability
Can Salesforce generate the required event volume?
Event transport scalability
Can the event infrastructure handle peak load?
Consumer scalability
Can consumers process events quickly enough?
Downstream scalability
Can downstream APIs, databases, and applications handle the resulting workload?
Operational scalability
Can the support organization monitor and recover the system?
A system is only as scalable as its weakest dependency.
43. Capacity Planning Should Start With Business Volume
Do not start with:
“How many Platform Events can Salesforce handle?”
Start with:
Customers
Orders
Transactions
Events per transaction
Peak transactions/sec
Consumers
Average payload size
Peak payload size
Retention requirements
Then calculate the architectural workload.
For example:
50,000 transactions/day
x
3 events/transaction
=
150,000 events/day
But average volume is not enough.
Architects should also model:
Normal load
Peak load
Burst load
Seasonal load
Failure/recovery load
Replay load
The recovery scenario can be especially important.
44. Security and Data Exposure
Events can distribute data to many consumers.
That creates a different security risk from point-to-point APIs.
If an event contains:
CustomerName
Email
Phone
Address
CreditInformation
every consumer receiving the event potentially receives that data.
Therefore event contracts should follow:
- least privilege
- data minimization
- appropriate classification
- consumer authorization
- encryption requirements
- audit requirements
- regulatory constraints
An event is not merely a technical message.
It is also a data distribution mechanism.
45. Governance: Treat Events as Enterprise Contracts
Once multiple applications depend on:
CustomerCreated
changing that event becomes an enterprise-impacting change.
Organizations should therefore consider an event catalog containing:
| Attribute | Example |
|---|---|
| Event | CustomerCreated |
| Owner | Customer Domain |
| Producer | Salesforce |
| Consumers | ERP, Data Platform |
| Version | 1.2 |
| Business meaning | Customer successfully onboarded |
| Schema | Defined |
| Criticality | High |
| Retention | Defined |
| Security classification | Confidential |
This turns event-driven architecture into a governed capability rather than an uncontrolled collection of messages.
46. Event Versioning
Events evolve.
Version 1 might contain:
customerId
name
email
Later consumers may require:
customerId
customerType
region
segment
Changing the contract without considering existing consumers can break integrations.
Therefore architects should design for:
- backward compatibility
- schema evolution
- versioning
- deprecation
- consumer migration
Event contracts should be treated similarly to APIs: they are integration contracts.
47. Measuring Event-Driven Architecture
Architecture teams should monitor more than event volume.
Useful metrics include:
Production
- events published
- events rejected
- publication latency
Consumption
- events consumed
- processing latency
- consumer throughput
Reliability
- failure rate
- retry count
- duplicate rate
- replay volume
Business
- orders processed
- customers synchronized
- failed business transactions
Operational
- lag
- backlog
- dead-letter volume
- recovery time
These metrics make event-driven architecture observable.
48. A Practical Architecture Review Checklist
Before approving a Salesforce event-driven integration, ask:
- What business fact are we publishing?
- Who owns that fact?
- Why is an event better than an API?
- Is eventual consistency acceptable?
- Who are the consumers?
- Are consumers independent?
- What is the expected event volume?
- What is the peak volume?
- What happens if the consumer is unavailable?
- Can the consumer safely retry?
- Is processing idempotent?
- Is ordering important?
- Can events be replayed?
- How is the event versioned?
- How is the event monitored?
- What data is being distributed?
- Is sensitive data included?
- Who owns the event contract?
- What happens when the event schema changes?
If these questions cannot be answered, the architecture is probably not ready for production.
49. Final Architecture Principle
The goal of Salesforce event-driven architecture is not to eliminate APIs.
It is to create the right interaction model for each business requirement.
A strong enterprise architecture typically looks like this:
Business Interaction
|
+----------------+----------------+
| |
Need immediate answer? Something happened?
| |
API Event
| |
Request / Response +----------+----------+
| |
Business Event Data Change
| |
Platform Event CDC
| |
+----------+----------+
|
Event Consumers
|
+------------+------------+
| | |
ERP Data AI
The architectural principle is simple:
APIs communicate intent. Events communicate facts. CDC communicates data changes.
The real skill of a Salesforce architect is knowing where each belongs, how they interact, and how to design the resulting architecture for scale, reliability, governance, and long-term evolution.
Key Takeaways
- Do not treat APIs and events as competing technologies.
- Use APIs for synchronous commands and queries.
- Use Platform Events for meaningful business events.
- Use CDC primarily for Salesforce data-change propagation.
- Use Pub/Sub API as an interface for interacting with Salesforce event streams.
- Event-driven architecture provides decoupling, not automatic scalability.
- Design consumers for retries, duplicates, failures, and replay.
- Treat event schemas as enterprise integration contracts.
- Design explicitly for eventual consistency.
- Use hybrid API + event architectures where appropriate.
- Do not make Salesforce the enterprise event broker by default.
- Start architecture decisions from business semantics, not Salesforce features.
The Architect’s Perspective
The most important question is not:
“Should we use Platform Events or APIs?”
It is:
“What kind of interaction are we modeling?”
If the interaction is:
“Please do this and tell me the result.”
Think API.
If it is:
“This business fact has occurred; interested systems may react.”
Think event.
If it is:
“This Salesforce data changed; downstream systems need to know.”
Think CDC.
And when those patterns need to participate in an external event-driven ecosystem, Pub/Sub API becomes part of the connectivity architecture.
That distinction is the foundation of a scalable Salesforce event-driven architecture.