How do you architect event-driven systems on Salesforce?

Event-driven architecture (EDA): components communicate via events rather than direct calls. Salesforce supports this natively.

Salesforce EDA primitives:

• Platform Events — custom event types (__e suffix).
• Change Data Capture (CDC) — auto-events on record changes.
• Pub/Sub API — modern subscriber protocol.
• Streaming API / CometD — older subscriber protocol.

EDA patterns:

1. System decoupling.

System A publishes event. System B (and C, D) subscribes. A doesn't know who's listening; B doesn't know A is sending.

2. Async workflows.

User triggers action -> event published -> async subscribers process -> results published as new event -> next system reacts.

3. Replay / catch-up.

Subscribers persist state of "last processed event". Catch up after downtime.

4. Event sourcing (lite).

Sequence of events represents state. Replay events to reconstruct.

5. Saga pattern.

Distributed transaction across systems via events. Each system reacts to events; compensating actions on failure.

Use cases:

• Order fulfilment chain — Order Created -> Inventory Allocated -> Shipping Scheduled -> Customer Notified.
• Customer 360 sync — Account Updated event -> downstream systems sync.
• Audit logging — every business event published; central logger captures.
• Inter-microservice communication — services on Heroku / external publish/subscribe via Salesforce events.

Architectural decisions:

1. Granularity.

• Fine-grained: many small events. Flexibility but potentially noisy.
• Coarse-grained: fewer big events. Simpler but less flexible.

Pick based on subscriber needs.

2. Schema evolution.

• Events have schema; changes can break subscribers.
• Versioning strategy: Order_Created_V1__e, Order_Created_V2__e.
• Or schema-flexible payloads with optional fields.

3. Reliability.

• 72-hour retention for missed events.
• Idempotency mandatory for subscribers.
• Replay capability.

4. Volume.

• Per-org event delivery limits.
• High-volume scenarios need careful throttling.

5. Cost.

• Platform Events have per-event costs at high scale.
• Compare to custom Pub/Sub (Kafka) for very high volume.

Anti-patterns:

• Synchronous-disguised-as-event — publishing events but immediately blocking on response. Misses the decoupling benefit.
• Event for every change — overhead exceeds value.
• No idempotency — duplicate processing causes data corruption.
• Tightly coupled subscribers — knowing too much about publishers.

Senior architect insight: EDA is powerful but requires discipline. Subscribers handle replay, idempotency, ordering issues. Without that discipline, EDA creates more bugs than it solves.

Use EDA for genuine decoupling needs. For simple synchronous request-response, EDA is overkill.