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

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

By: Nathan Neikirk, Salesforce Consultant

This May, I was fortunate enough to attend my first Salesforce conference – Texas Dreamin’. Texas Dreamin’ is an annual community-led conference that brings together Salesforce enthusiasts from all corners of the Lone Star State. Led by a passionate group of Salesforce Community leaders, the event aims to empower Salesforce customers, administrators, developers, and partners through a vibrant mix of knowledge-sharing, skill-building, and networking. Conference content embraces those interested in pursuing a Salesforce career or those already using Salesforce, creating a dynamic atmosphere for building meaningful connections and propelling professional growth.

There were over 75 sessions at this year’s conference, but one topic dominated my conference schedule: Event-Driven Architecture, with a particular focus on Pub/Sub APIs and Salesforce Platform Events. During these sessions, I was able to further explore these subjects, discovering how these technologies can revolutionize Salesforce development and integration. Leaving the conference, I was really excited about the future of event-driven architectures and their potential to transform Salesforce workflows.

This is Part 1 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)

  • What are Event-Driven Architectures?
  • Benefits of Traditional Point-to-Point Architectures
  • Drawbacks of Point-to-Point Architectures

Part 2: Classifying Event-Driven Architectures

Part 3: Event Driven Architecture in Salesforce

Part 4: Should YOU implement Event Driven Architectures?

What are Event-Driven Architectures?

Event-driven architectures facilitate the generation and processing of events, reflecting changes in system states. They enable flexible integrations between systems, support cross-system processes, and enable near real-time updates across multiple systems. As the benefits of event-driven architectures become more evident, the implementation specifics can be complex and nuanced. Therefore, we should ask ourselves:

  • When should we implement an event-driven architecture?
  • Why should we move away from point-to-point integration solutions?
  • What specific challenges do each one of these patterns address?
  • What are the key considerations and optimal strategies for implementing event-driven architectures, particularly those involving Salesforce?
Benefits of Traditional Point-to-Point Architectures

Traditional point-to-point architectures are a straightforward and effective approach to system integration, particularly in smaller-scale environments.

 

Here, let’s explore the key benefits that make this architecture appealing for certain use cases:

Ease of Use & Control

Direct Connections: In point-to-point architectures, systems are connected directly to each other. This directness simplifies the setup and makes it easier to trace data flow, making it straightforward to identify and fix issues.
Clear Data Paths: Since each connection is explicitly defined, the path that data takes between systems is clear and predictable, allowing for more precise control over how data is processed and transmitted.

Lower Learning Curve

Familiarity: Developers and architects often find point-to-point integration intuitive because it mirrors traditional software development practices. The concepts and methodologies are well understood, reducing the need for extensive training.
Immediate Productivity: Because of its simplicity, teams can quickly start implementing point-to-point integrations without specialized knowledge or complex middleware.

Familiar Tools for Developers/Architects

Standard Protocols: Point-to-point integrations typically use well-known protocols and tools (e.g., RESTful APIs, SOAP, FTP), which are familiar to most developers.
Established Practices: There is a wealth of resources, best practices, and community support available for these standard tools and protocols, making it easier to design and troubleshoot integrations.

Synchronous Processing

Real-Time Interaction: Point-to-point systems often operate synchronously, meaning that a request is immediately followed by a response. This is beneficial for applications requiring real-time data exchange and immediate processing results.
Immediate Feedback: Synchronous processing provides instant feedback on the success or failure of an operation, which can be crucial for user-facing applications where timely responses are necessary.

Efficiency and Maintenance

Simplified Maintenance: With fewer moving parts and a direct line of communication between systems, maintaining point-to-point integrations is often simpler. Issues are easier to isolate and resolve, reducing downtime and maintenance efforts.
Minimized Latency: Direct connections typically result in lower latency compared to more complex architectures that involve multiple intermediaries or message queues.

Less Overhead

Reduced Complexity: Point-to-point architectures do not require additional infrastructure such as message brokers or service buses, which reduces the overhead associated with managing and maintaining these components.
Cost-Effective: The absence of intermediary layers can lead to lower infrastructure and operational costs, making point-to-point integration a cost-effective solution for many scenarios.

Suitable for Small-Scale System Needs

Scalability Not Always Required: In smaller environments, the scalability limitations of point-to-point architectures are not as problematic. The simplicity and direct nature of these integrations can be sufficient and advantageous.
Tailored Solutions: For specific, well-defined tasks or integrations that don’t require complex orchestration, point-to-point solutions can be perfectly tailored to meet the exact needs of the systems involved.

 

Drawbacks of Point-to-Point Architectures

While point-to-point architectures offer more simplicity and ease of use, they come with several drawbacks. These drawbacks can lead to increased technical debt, especially as the IT organization grows and their systems become more complex. Below, we’ll highlight these limitations in detail:

Data Consistency

Inconsistent Data States: In point-to-point architectures, each system manages its own data update. Without a centralized coordination mechanism, different systems might have differing versions of the same data, causing discrepancies.
Synchronization Challenges: Ensuring data consistency across multiple systems requires complex synchronization logic, which can be difficult to implement and maintain. The lack of a unified approach to data management increases the risk of errors and data corruption.

Reusability

Duplicated Efforts: Point-to-point integrations often result in duplicated code and logic across different systems. Each integration needs to be individually coded and maintained, leading to repetitive efforts and higher maintenance costs.
Limited Code Reuse: The highly specific nature of point-to-point connections means that the code and logic developed for one integration are rarely reusable for others. This lack of reusability can slow down development and increase the likelihood of inconsistencies and bugs.

Scalability

Integration Sprawl: As the number of systems and connections grows, managing a point-to-point architecture becomes increasingly complex. Each new integration adds to the overall system complexity, leading to an “integration spaghetti” where connections are tangled and hard to manage.
Performance Bottlenecks: Point-to-point integrations can become bottlenecks as the number of interconnected systems increases. Each system needs to handle multiple direct connections, which can strain resources and diminish system performance.

Extensibility

Rigid Connections: Point-to-point architectures create rigid and tightly coupled connections between systems. Making changes to one system often requires corresponding changes to all connected systems, which can be time-consuming and error-prone.
Difficulty in Adding New Systems: Adding a new system to a point-to-point architecture involves creating new integrations for each existing system it needs to connect with. This process can be labor-intensive and slow, hindering the organization’s ability to quickly adapt to new requirements or technologies.

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.