Salesforce Platform Events And Real-Time Integrations

What's being tested

This topic tests whether you can design and debug event-driven distributed systems around Salesforce without assuming stronger guarantees than the platform provides. A Software Engineer should be able to choose between Platform Events, Change Data Capture (CDC), synchronous APIs, and the Pub/Sub API, then explain delivery, replay, ordering, duplication, failure recovery, and security. Salesforce cares because integrations must remain reliable under bursts, consumer outages, transaction failures, and partial downstream availability—not merely work in a happy-path demo.

Core knowledge

• Platform Events are custom, append-only messages published through Salesforce’s event bus. Publishers use Apex, Flow, REST, SOAP, or APIs; subscribers consume asynchronously, decoupling the Salesforce transaction from downstream processing.

• CDC describes changes to Salesforce records, while Platform Events describe application-defined business facts. Use CDC for synchronization such as “Account changed”; use a custom event for intent such as “Invoice approved.” Do not treat them as interchangeable.

• The Pub/Sub API uses gRPC and supports high-throughput event consumption with topic schemas, replay, and flow control. CometD uses Bayeux over HTTP long polling and remains common for clients subscribing through /cometd/{version}.

• Delivery is generally at least once, so a consumer must tolerate duplicates. Include a stable event identifier such as EventUuid, persist processed IDs or a business idempotency key, and make the side effect transactional with the deduplication record where possible.

• Replay lets a subscriber resume from an event position after disconnecting. Store the last successfully processed replay position durably, but avoid acknowledging or advancing it before the downstream side effect commits.

• Do not promise global ordering. Events may be ordered within a limited publishing context or stream, but multiple publishers, partitions, retries, and independent consumers can produce reordering. Include a source timestamp, sequence number, or version and define conflict behavior.

• Salesforce publication is coupled to the originating transaction: a rollback generally prevents the event from being committed. After commit, delivery to subscribers is asynchronous; the publisher should not assume the consumer has completed before the API request returns.

• Backpressure prevents a fast producer from overwhelming a slow consumer. Bound in-memory queues, use controlled concurrency, monitor lag, and apply exponential backoff with jitter. A retry storm is worse than a temporarily slow consumer.

• Design a dead-letter path for poison messages that repeatedly fail validation or downstream processing. Preserve the original payload, event ID, error, attempt count, and timestamps; support replay after correcting code or data rather than silently dropping the event.

• A useful reliability decomposition is:
  $P(\text{successful end-to-end processing}) \approx P(\text{publish}) \times P(\text{delivery}) \times P(\text{consumer success})$
  Measure each stage separately with publish errors, subscriber lag, processing failures, and downstream latency.

• Schema evolution must be additive where possible. Consumers should ignore unknown fields, tolerate missing optional fields, and use explicit event versioning for incompatible changes. Never overload one field with a new meaning merely to avoid a schema update.

• Apply least privilege using Salesforce Connected Apps, OAuth scopes, integration users, and subscriber authorization. Do not put secrets in event payloads; encrypt sensitive data, minimize fields, and remember that events can be retained or replayed.

Worked example

Representative prompt: Design a reliable Salesforce Platform Event integration

In the first 30 seconds, clarify the event volume and burst rate, acceptable end-to-end latency, retention and replay requirements, ordering scope, downstream side effects, and whether duplicate processing is tolerable. I would state the assumption that delivery is asynchronous and at least once, so the consumer must be idempotent rather than relying on exactly-once delivery. I would organize the answer around four pillars: event contract and publication boundary, subscriber transport and checkpointing, idempotent processing with retries, and observability/security. The consumer would read through Pub/Sub API or CometD, persist a durable checkpoint only after successful processing, and route repeatedly failing events to a dead-letter store. I would explicitly choose between synchronous confirmation and asynchronous publication: synchronous APIs provide immediate business feedback, while Platform Events improve decoupling but shift failure handling into the consumer. I would also explain that a database uniqueness constraint on (event_id, operation) is stronger than an in-memory duplicate cache. Finally, I would close with: if I had more time, I would load-test burst behavior, simulate subscriber outages and replay gaps, and verify schema compatibility during rolling deployments.

A second angle

Representative prompt: How would you prevent duplicate downstream actions from a Salesforce event stream?

Here the central constraint is not transport selection but the boundary between event consumption and an irreversible side effect such as charging a card or sending a fulfillment request. The strong framing is to distinguish deduplication from retry: deduplication recognizes a previously completed operation, while retry handles an unknown outcome after a timeout. Use an idempotency key accepted by the downstream service, or persist an operation state machine such as PENDING, SUCCEEDED, and FAILED with a unique event key. If the side effect and local database update cannot share one transaction, acknowledge the distributed limitation and use reconciliation or an outbox-style completion record.

Common pitfalls

Pitfall: Saying “Platform Events guarantee exactly-once processing” is analytically wrong. State at-least-once delivery and design idempotency, durable checkpoints, and replay handling explicitly.

A common communication mistake is starting with Kafka, microservices, or generic event-bus terminology without clarifying Salesforce constraints. Lead with the required guarantee, volume, consumer type, and failure model, then map the design to Pub/Sub API, CometD, Platform Event limits, and Salesforce authentication.

A depth mistake is discussing retries without explaining what happens after a consumer crashes between the downstream call and the acknowledgment. A stronger answer names the ambiguous-outcome case and proposes downstream idempotency keys, transactional state, reconciliation, and a dead-letter workflow.

Connections

An interviewer may pivot to distributed transactions, the transactional outbox pattern, Change Data Capture, or API rate-limit and backpressure design. They may also test schema compatibility, OAuth integration security, observability through p95/p99 latency and consumer lag, or how to test replay and failure recovery.