Event-Driven Architectures at Texas Dreamin’: Part 4

Should YOU implement an Event-driven Architecture?

By: Nathan Neikirk, Salesforce Consultant

This is the final part 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

Part 3: Event Driven Architecture in Salesforce

Part 4: Should YOU implement Event Driven Architectures?

  • When to Use Event Driven Architectures
  • Event-driven Architecture Best Practices
  • Moving away from Point-to-Point Architectures

When should you use Event-Driven Architectures?

These scenarios highlight the versatility and effectiveness of Event-Driven Architectures across various use cases in modern IT landscapes.

  • Sending Data to Multiple Systems: Suitable for scenarios requiring data duplication across systems.
  • System Notifications: Useful for broadcasting internal/external system alerts or messages.
  • Notification-based Integrations: Ideal for systems that require notifications of status changes or updates.
  • Debugging: Facilitates tracking and logging events for debugging purposes.
  • Delivery of Small Payloads: Effective for transmitting lightweight data efficiently.
  • Decoupling of System Processes: Allows independent development and scaling of system components.
  • Performance Improvement: Pub/Sub API demonstrates significant performance gains over traditional synchronous REST integrations.
    • One of the sessions that I attended (Demystifying Pub/Sub API) highlighted test results from 200 Pub/Sub API interactions against 200 REST API interactions. Pub/Sub outperformed in all benchmarks.
  • Parallel Processing: Distributes a processing load across multiple systems for scalability.
  • High-Volume Reads and Writes: Handles surges in message production and consumption efficiently.
  • Offline Mobile Devices: Queuing patterns enable devices to retrieve missed messages when they come back online.
  • IoT Device Integration: Manage frequent updates from IoT devices. When new IoT devices are made available, easily integrate these devices without implementing new custom point-to-point integrations.

Moving away from Point-to-Point Architectures

If you’re convinced that an event-driven architecture suits your organization’s needs, starting with numerous point-to-point integrations can present challenges. Securing funding for a comprehensive replacement project can be daunting, especially when some legacy systems may not directly support event-driven models. In such cases, an incremental migration approach might be most effective. Begin by converting key applications first, then gradually transition other systems during future updates or replacements. This method facilitates the seamless addition of new applications to the event bus, ensuring scalability and resilience as your IT landscape evolves over time.

Recap and Takeaways

  • While Point-to-Point architecture benefit from their simplicity, control, and cost-efficiency, there can be issues with their consistency, reusability, scalability, and extensibility as the system grows. Transitioning to more advanced patterns can mitigate these issues and support sustainable growth.
  • Consider Salesforce’s event-driven solutions for non-real-time business activities!
  • Utilize Platform Events or Change Data Capture (CDC) for publishing record and field changes intended for consumption by other systems.
  • Leverage the Pub/Sub API over implementing custom event handlers for publish/subscribe integration patterns.
  • If you haven’t already, start developing a strategy to migrate existing event communications from other Salesforce platform APIs (e.g., Streaming API, custom Apex Web Services) to Pub/Sub API when feasible.

Event-Driven Architecture Best Practices

These practices help in effectively leveraging Salesforce Platform Events while mitigating common anti-patterns and optimizing system performance and stability.

  • Monitor Your Event Usage: It’s crucial to monitor event usage against allocated limits to prevent service disruptions, manage costs, optimize performance, ensure compliance, plan capacity, identify unusual activities, and maximize ROI.
  • Internal Communication Workaround: Avoid using platform events as a workaround for synchronous internal communications within your Salesforce org. This can lead to inefficiencies and misuse of event allocation limits. Platform Events are meant to facilitate integration with external systems.
  • Correct Use of Real-time Events: Use real-time platform events judiciously, understanding their immediate publishing nature and potential impact on transactional integrity, especially in scenarios like logging.
  • Selective Event Handling: Ensure event handlers execute selectively when multiple components listen for an application event, avoiding unnecessary processing.
  • Payload Optimization: Minimize payload size when sending and receiving data to improve transport efficiency and processing times.
  • Flow Orchestration: Use subflows or Flow Orchestrator instead of platform events for executing logic across multiple automations to avoid event allocation limits.
  • Infinite Trigger Loops: Publishing events from Apex triggers associated with the same event object can trigger infinite loops, impacting system stability.
  • Transactional Considerations: Be cautious when publishing events from Apex before DML transactions complete, as event publishing may not roll back with transaction failures.
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
  • This field is hidden when viewing the form
  • This field is for validation purposes and should be left unchanged.