Event-Driven Architectures at Texas Dreamin’: Part 2

Classifying Event-Driven Architectures

By: Nathan Neikirk, SALESFORCE CONSULTANT

When dealing with Event-Driven Architectures, understanding the differences between Pub/Sub APIs and Streaming APIs is crucial when selecting the right approach for your event processing needs. Both paradigms facilitate the handling and distribution of events, but they differ in terms of how they operate, their use cases, and their implementations.

This is Part 2 of a series to walk through Event Driven Architecture with insights from Texas Dreamin’ sessions and Salesforce leading practices to better equip you for future implementations for Event-Driven.

Event-Driven Architectures at Texas Dreamin’: A 4-part Series

Part 1: Introduction to Event Driven Architecture (vs. Point to Point)

Part 2: Classifying Event-Driven Architectures

  • Pub/Sub APIs
  • Streaming APIs
  • Comparing Pub/Sub vs. Streaming APIs

Part 3: Event Driven Architecture in Salesforce

Part 4: Should YOU implement Event Driven Architectures?

Pub/Sub APIs

Purpose
  • Pub/Sub APIs support the publish-subscribe pattern where a producer sends events to a channel (event bus), and consumers subscribe to this channel to receive events.
  • Pub/Sub APIs are designed to facilitate asynchronous communication of events internally and externally to the system.

Key Characteristics

  • The Pub/Sub pattern falls into the general integration pattern known as remote procedure invocation/remote process invocation/fire and forget.
  • The subscription model for pub/sub is pull-based. The client requests the number of events to receive from the event bus.
  • Ideal for scenarios where the event producers and consumers are loosely coupled and require reliable event delivery.
  • Suitable for real-time notifications and updates, such as integrating Salesforce with external systems or triggering workflows.
  • The same system can be both the publisher and the subscriber
  • Systems may publish or subscribe to multiple types of events
  • There is no direct connection between publishers and subscribers. Publishers simply send messages to an event bus, which broadcasts them out to any other system that wants to listen to them.
  • Subscribers can replay events starting from a specific point in time, which is useful for recovery scenarios.

Use Cases

    The publish/subscribe pattern is best fitted for scenarios in which a single source system needs to send the same message to multiple target systems. Pub/Sub APIs should also be used when you need robust deliver of events to applications that may recover from outages. Examples of this may be:

  • Chat/Messaging
  • IoT Device Communications
  • Order Management
Streaming APIs
  • Streaming APIs provide a mechanism to receive real-time notifications of changes or events based on predefined criteria set in subscriptions.
  • They are typically used for monitoring data changes, such as updates to records, without the need for continuous polling, thus saving bandwidth and improving performance.
Key Characteristics
  • The Streaming API can be considered a specialized implementation of the Pub/Sub pattern.
  • Streaming APIs push notifications to clients in real-time as soon as a change occurs.
  • The subscription model for Streaming API is push-based. The server delivers events as they become available in the event bus.
  • Event streaming services publish streams of events. Subscribers access each event stream and process the events in the exact order in which they were received.
  • Unique copies of each message stream are sent to each subscriber, which makes it possible to guarantee delivery and identify which subscribers received which streams.
  • Various types of Streaming APIs offer different levels of granularity and use cases. In Salesforce, PushTopics can be used for specific fields, while Change Data Capture is suitable for comprehensive data change tracking.
Use Cases
    The streaming pattern is best suited for applications that require immediate updates, real-time data sync, or Audio/Visual feeds. Examples of this may be:

  • Live Dashboards
  • Alerts & Monitoring Tools
  • Streaming Media
Comparing the Streaming API and Pub/Sub API
  • The Streaming API is focused on real-time data events, whereas the Pub/Sub API offers broader functionality to accommodate different messaging patterns and comprehensive communication requirements.
  • The Pub/Sub API is a more versatile messaging service that caters to a wider array of communication needs beyond data changes.
  • While the Streaming API has traditionally been used for event monitoring in Salesforce, the Pub/Sub API offers greater scalability and advanced event handling. Depending on your integration requirements, you might choose one over the other. However, for typical event monitoring, the Streaming API remains widely used and effective.
  • The Pub/Sub API is a newer API that you can use to publish and subscribe to platform events or change data capture events. Based on the gRPC API and HTTP/2, Pub/Sub API publishes and delivers event messages with support for multiple programming languages. Before Pub/Sub API was introduced, the only way to subscribe to events in an external client was through the Streaming API. This table compares features of the two APIs.
  • The format of change events received with Streaming API differs from change events received with Pub/Sub API. Streaming API delivers the entire event message in JSON format while Pub/Sub API delivers the event payload in the Apache Avro binary format.
  • If you’re writing an app for publishing and subscribing to platform events and change data capture events, you should consider using Pub/Sub API instead of Streaming API. Additional differences are highlighted below.
Resources:
  • https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro_emp.htm
  • https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm
  • https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_limits_monitor.htm
  • https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_limits_svpe.htm
  • https://medium.com/salesforce-architects/the-new-salesforce-event-bus-f82165cb0585
  • https://www.salesforceben.com/salesforce-platform-events/
  • https://architect.salesforce.com/diagrams/design-patterns/publish-subscribe
  • https://trailhead.salesforce.com/content/learn/modules/realtime-event-monitoring/get-to-know-realtime-events-and-transaction-security
  • https://dzone.com/articles/salesforce-event-driven-architecture-using-platfor#:~:text=Publish
  • https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro_other_events.htm
  • https://architect.salesforce.com/decision-guides/event-driven#When_Should_You_Not_Use_Event_Driven_Architectures_
  • https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/pubsub_api_streaming_api_comparison.htm
  • https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/cdc_event_diff_pubsub_cometd.htm
  • https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/using_resources_event_log_files.htm
  • https://help.salesforce.com/s/articleView?id=sf.real_time_event_monitoring_streaming.htm&type=5
  • https://trailhead.salesforce.com/content/learn/modules/platform_events_basics/platform_events_architecture
  • https://trailhead.salesforce.com/content/learn/superbadges/superbadge-events-sbu
  • https://www.absyz.com/introduction-to-streaming-api/
Texas Dreamin’ 2024 Special Thanks to:

Platform Events Revisited:

  • Rick Locke – Senior Technical Architect, Komodo Health
  • Jeremy Hayes – Senior Technical Architect, Komodo Health

Demystifying Pub/Sub API:

  • Federico Henderson – Salesforce Tech Lead, Altimetrik
  • Gabriel Juarez – Salesforce Tech Lead, Nearsure

Platform Events vs. Mixed DML, How Admins Can Win the Day:

  • Michelle Hansen – Principal, Slalom
  • Hidden
  • This field is for validation purposes and should be left unchanged.