How would you architect a real-time integration with an external system?

"Real-time" usually means sub-second latency between an event in one system and observable effect in the other. Multiple approaches with different trade-offs.

Inbound (external -> Salesforce):

1. Webhooks via Apex REST endpoint. External system POSTs on event; Apex processes. Sub-second if processing is fast. Requires public endpoint, signature verification, idempotency keys.

1. Streaming connection (Pub/Sub API or CometD). External system subscribes to Salesforce events for real-time outbound — but for inbound it's webhooks.

1. Push from external via Bulk API 2.0. For high-volume bursts, external batches and pushes; not strictly real-time.

Outbound (Salesforce -> external):

1. Platform Events + Pub/Sub API subscriber. Salesforce publishes; external subscribes. Sub-second delivery; built-in retry within 72-hour window.

1. Change Data Capture + Pub/Sub API. Same as above but auto-fired on every record change.

1. Outbound Messages (legacy). SOAP-based; reliable retry. Use only when external is locked into SOAP.

1. Apex callout from a trigger (asynchronously via Queueable). Fires after commit. Single-record latency low; bulk operations may queue.

Bidirectional / orchestrated:

• Mulesoft / iPaaS in the middle. External pushes to Mulesoft; Mulesoft to Salesforce. Salesforce events to Mulesoft; Mulesoft to external. Centralised retry, error handling, transformation.
• Event-driven architecture: every system publishes events; consumers subscribe. Salesforce as one node, not the centre.

Key considerations:

• Latency budget: webhook + Apex processing typically 100-500ms; OK for most "real-time" needs.
• Throughput: high-volume orgs need batching / async to stay under limits.
• Idempotency: every consumer must safely handle duplicate events.
• Retry logic: who retries? For how long? With what backoff?
• Failure handling: what if Salesforce is down? What if external is down? Persistent queue (Mulesoft, Kafka, AWS SQS) decouples.
• Order: events from the same record may arrive out of order. Use timestamps for resolution.
• Security: signature verification, IP allowlisting, OAuth, encrypted transit.

Recommendation:

• Small org, simple integration -> webhooks + async processing.
• Larger org, multiple integrations -> Mulesoft/iPaaS for orchestration.
• Event-heavy architecture -> CDC + Pub/Sub API as the backbone.

Real-time isn't free; latency, reliability, and complexity are constant trade-offs. Pick the architecture that matches the SLA, not the buzzword.