Event-Driven Architecture Guide for the Modern Salesforce Developer

Introduction: The Tightly Coupled Enterprise Issue

For many years, the architectural style employed in connecting the customer relationship management systems to enterprise resource planning systems and microservices in a way that is external to the latter was tightly coupled and brittle. This involved direct point-to-point connections between the two using REST or SOAP application programming interfaces. Here, in this traditional setup, the moment a sales representative tags an opportunity as being closed-won within the core customer relationship management system, a chain reaction of remote procedure calls occurs. The CRM system keeps its database transaction open and then calls the inventory microservice and waits for the response. It then calls the billing platform, and waits again before trying to update the on-premise ERP system.

Synchronous coupling leads to tremendous systemic weaknesses. The CRM transaction is hostage to the weakest or the most unreliable external component in the chain. In case the ERP system goes for scheduled maintenance, experiences thread pool exhaustion or faces temporary network partition, the originating transaction in the CRM gets interrupted. The end-user sees a general error message, the record gets rolled back, business process comes to a standstill, and developers have to search through fragmented logs in order to identify the failing system and the inconsistency of the data.

Apart from reliability problems, the other issue is that tight coupling seriously impacts the velocity of the company. Any new business requirement requires changes to be made in integration points. In case some marketing platform or analytics engine has to know about changes in high-value accounts, developers have to add changes to the originating business logic within the CRM platform, making one more HTTP callout.

Event-driven architecture modernizes this concept by transitioning systems from direct straightforward interaction to asynchronous sharing of state. Rather than relying on one system sending a command to other systems via synchronous communication, systems send out messages called events to signal that something significant has already happened. The downstream subscribers, whether they include distributed microservices, enterprise service buses, or legacy ERP monoliths, consume this event stream independently and don’t care about publishers supplying them with this information.

Within Salesforce Platform, event-driven architecture comes through two significant components: Platform Events and Change Data Capture. If used properly, these inherent technologies can enable enterprise architects to separate core CRM functions from helpful microservices and huge ERP systems.

The Conceptual Framework of Event-Driven Architectures

The event bus is the backbone of any event-driven architecture. In contrast to the message queue, which typically delivers a message to a single consumer who reads and removes the message, the event bus acts like a log that stores event data sequentially and is not considered a robust solution. Events published on the bus do not have defined characteristics but exist through their sequencing, timestamping, unique identifiers that allow for replay, and preserving the record for a limited period even if there is no user.

This log-based approach offers temporal decoupling. Meanwhile, the publisher and the consumer do not have to be online simultaneously. While at the peak hour the CRM is able to publish hundreds of transactions per second, a downstream micro service may be temporarily unavailable due to system updating and will not miss any transaction.

As soon as the consumer comes online again, it continues to read from where it has stopped – receiving events in the same manner without causing the originating system to experience backpressure.

The events can generally be divided into the following classes: domain events and data-change events. It is essential to understand the difference between these two notions when it comes to selecting the appropriate architectural pattern.

Domain events are conscious business propositions that have semantic meaning attached. They serve as important events in the business sector, which are greater than just database schemas. Order Activated, Invoice Dispute Raised, and Patient Check-In Completed are the examples of business events. The events have some kind of enriched content that gives the context only for external enterprise consumers.

In contrast, data change events are a detailed and mechanical representation of low-level data change events in the registering system. Each time a specific record is inserted, altered, deleted or recovered, an event takes place. The event described what particular data fields changed and what current or old value they had. Although data change events do not include a high-level business abstraction, they make data state changes highly observable.

Salesforce assures that customers can utilize appropriate enterprise techniques for both data types, such as use of Platform Events for developing particular static events, and provision of Change Data Capture for automatic, reliable data change events from a transaction log.

Platform Events: Declarative and Programmatic Domain Messaging

Platform Events allow developers and enterprise architects to create their own event schemas in the CRM. They are created in the same way as custom objects: each has custom fields, validation rules, and other metadata information. However, unlike in case of custom objects, Platform Events do not take their place in standard relational tables, do not take their part of database record storage, and cannot be queried with the help of standard object query languages. Thus, they represent schemas through which messages are passed via the enterprise event bus.

Choosing publish behavior is a crucial design decision when handling Platform Events. Publish behavior determines what the relation of the local database transaction to message dispatch will be. Salesforce has two types of publish behavior: publish after commit or publish right away.

Publish after commit is the basic pattern for transactional integrity. An event configured to be published after commit will have its message go to an internal staging area when running. The event will be put on the distributed bus when the associated database transaction commits. If a runtime exception occurs, a governor limit is violated, or a validation rule does not pass, the entire transaction is rolled back and the event is discarded. This avoids producing phantom events where an external ERP or microservice is informed that an order has completed only for the CRM to later roll back the record insertion due to an unexpected downstream error.

On the other hand, Publish right away skips the commit cycle of transactions. With this pattern, the event is placed on the event bus as soon as the publish command is executed regardless of the outcome of the transaction. It is important to understand that while Publish immediately cannot be used for transactional updates to business status it is a very useful system for distributing logs, audit trails, and telemetry. When some complex batch process fails and has to roll back all of the database operations it initiated, an immediately published event can allow the network monitoring solution to collect the necessary diagnostic information from the failed process.

With Platform Events, the producer and consumer of events are effectively separated by employing a highly efficient standard publish-subscribe approach which works in a unidirectional manner. The publishing of events to Salesforce from outside microservices happens by executing the standard lightweight HTTP POST on the REST-streaming resource or alternatively, it can be achieved by publishing to channels using gRPC-based Pub/Sub API. The development group in Salesforce has the right to use several ways of managing incoming events such as asynchronous event triggers and automated flows, for instance. The salesforce dev training in the field is based on combining these programmatic and declarative approaches in structured training for the purposes of practical enterprise work.

Change Data Capture: Seamless Operation Synchronization

Though the Platform Events function well to deliver well-planned and structured commercial milestones, enterprise software synchronization can further require the realization of core database states in different records. Traditionally such a need was met by different job schedules of extract-transform-load process, non-transparent work of database triggers that connected to http, or using method of “continuous polling” when external systems query the CRM for data every minute.

However, all these methods are associated with serious drawbacks. Continuous polling exhausts the available volume of API requests, leads to stress on database processing, and creates artificial lateness.

Change Data Capture removes these inefficiencies due to direct access to the database transaction log. When Change Data Capture is activated for any object, even a custom one, events will be generated and shared every time a creation, an update, a deletion, or undelete transaction is carried out.

Importantly, Change Data Capture works entirely separately from the database transaction and asynchronously. The action of generating the change event is performed outside of the user/system updating the record. This results in virtually no impact on the original database transaction, there are no CPU limits of the Salesforce Apex, and no delays due to slow and/or failed integration processes.

The Content of a Change Data Capture event is exclusively optimized for the purpose of distributed data replicating . It contains a lot of header metadata that includes: entity name, type of change, transaction key, timestamp for the moment of finishing all operations and id of the user who has initiated the change. When the operation is created the payload includes the full state of the record. When the operation is updated the payload uses a so-called sparse field set so that only the fields which were changed are included together with the unique record id. Thus, a sparse design reduces the network usage and the necessary processing power for both the event bus and its subscribers.

Moreover, Change Data Capture ensures that transaction boundaries are kept during commit grouping. In other words, if a company’s batch process, automation, or bulk integration makes updates of one thousand account records in one database transaction, then one key and sequence number will be attributed to all one thousand change events emitted. An advanced downstream consumer, for instance an enterprise data warehouse or ERP synchronization service, can look into this metadata and determine how to treat this transaction as a single operation so as to keep the level of referential integrity in good standing within the whole enterprise.

Technical Comparison: Platform Events Compared to Change Data Capture

Deciding between Platform Events or Change Data Capture is one of the most important architectural decisions for Salesforce in an enterprise. Both methods make use of the same event bus, however, they fulfill completely different operational purposes.

Platform Events are designed as a conscious act of abstraction. The architect or developer specifies the event definition meaning what data he wants included in the platform event, and when he wants to send it. Such an approach is perfect for use cases where an event trigger is needed to execute a work process across multiple systems without the target system needing to understand how things work inside the CRM database. For example, when the system processes a billing request the ERP should not need to know that 40 different fields for 3 custom objects were updated, it only needs to receive a simple well-defined message with an order ID, customer billing account number, line items, and amount.

Change Data Capture denotes complete transparency in the process. Owing to it, there is no need to design a new schema manually, no need to adopt any new publishing logic, and no need to carry out ongoing maintenance procedures when new custom fields are introduced to a particular object-the event stream in this case automatically adjusts to the changes in the schema. Thus, Change Data Capture is the best option for effective data replication, master data management, distributed caching, real-time analytics collection, and audit logging processes. If an enterprise aims at keeping its CRM customer database mirrored within AWS Aurora PostgreSQL database or any other enterprise ERP application without any coding, it can achieve it by using Change Data Capture.

Platform Events offer a lot of possibilities regarding their implementation when it comes to lifecycle and management. Knowing when to use custom event architecture instead of using standard change tracking is one of the key lessons you’ll learn in an advanced salesforce development course. They can originate from a person, workflow automation, program, or any external system, and they can be filtered, validated, and augmented at the time of publication. Change Data Capture, on the other hand, does not allow for any programmatic intervention prior to publication: it occurs on database commit. But Change Data Capture does offer several advantages over Platform Events since it includes enterprise functionalities such as recording deleted records automatically, field values before and after the changes when enriched, and using transaction commit identifiers out-of-the-box.

The Separation of Core CRM From Enterprise ERP Systems

Enterprise resource planning systems like SAP S/4HANA, Oracle ERP Cloud, and Microsoft Dynamics 365 function as the transaction backbone for areas such as financial management, supply chain, manufacturing, and inventory management. The relationship between CRM and ERP is characterized by tension at the level of architecture. CRMs are agile customer-oriented systems that emphasize rapid evolution of data schema and real-time interaction by sales and service representatives. ERPs are highly specialized systems of record that facilitate strict accounting practices and record-keeping.

Linking the two systems by means of synchronous point-to-point APIs is a wrong practice in the industry that will absolutely result in performance deterioration and some problems in operations. When a purchaser orders a complex product in the CRM, an attempt to run pricing process, perform credit verification, allocate the necessary stock, and execute entries into the ledger via the REST connection when the salesperson is saving the operation on the screen may lead to a very unstable user experience.

The implementation of an event-driven architecture of Platform Events and Change Data Capture will allow the CRM and ERP to function at a distance through non-synchronous events.

Let’s use the example of the quote-to-cash process. In this model, the sales agent sets the order status to activate in the CRM. Then, record-driven automated or domain services complete inspection of the information and send a Platform Event Order Completed. The transaction in the CRM is committed immediately and the salesperson receives a notification.

An enterprise integration layer that could be realized either using a lightweight event router or directly through the Salesforce Pub/Sub is available at the back-end and consumes the Order Finalized event from the event bus that has been established before the integration worker uses the particular domain event data and processes the information in a required format needed for the ERP and updates ERP operational level as well.

When the order is being processed and invoice number is generated, the ERP does not call the CRM through a synchronous REST update for modifying the order record. To notify the order status to the CRM, the ERP creates its own event (such as Fulfillment Scheduled) and sends this event back to the event bus.

When the sales officer finalizes the order, but the ERP is down during a weekend database update, it does not cause disruption in the business process. The event is stored safely on the event bus due to the retention period of the event. Once the ERP gets back online, the integration Bridge will start reading the event stream, clear all pending orders in the system, and perform the necessary transactions without any issues. Zero downtime, zero errors, and zero rollbacks for any CRM user.

Decoupling Microservices and Distributed Backend Architecture

Modern enterprises have started increasingly relying on those cloud software solutions (AWS, GCP, Azure) that enable working with integrated distributed microservices, which is required for performing certain computing tasks like credit score checking, fraud detection, complex algorithm pricing, using machine learning for producing recommendations, document generation, etc.

The integration of a monolithic CRM with these microservices through synchronous HTTP callouts gives rise to the distributed monolith issue. In this situation, the services become incapable of operating independently, thus making deployment a need to be accompanied by strict coordination between all parties involved, and latency occurs across the call graph.

Change Data Capture and Platform Events are perfect solutions to establish an event-driven integration mesh connecting Salesforce and distributed microservices.

Asynchronous Offloading of Heavy Computation

Suppose that we have a scenario of a high-traffic insurance platform in which submitting a claim via CRM requires a thorough fraud check, accident pictures processing and actuarial risk modeling. Due to the strict governor limits that have been put into place regarding processing time, heap size, and external callouts. How one should work within the performance constraints while using streaming data patterns is often covered in detailed salesforce developer online training.

When an event-driven approach is used to create a claim record, a Change Data Capture event is automatically generated. In turn, the series of autonomous microservices operating in a containerized cloud environment subscribes to the claims change stream. Each of these microservices operates autonomously:

• The fraud detection microservice analyzes the claim data, applies statistical anomaly detection techniques based on the previous fraud occurrences, and finds the risk level.

• The media processing microservice downloads the uploaded damage photograph, makes computer vision processes to detect car damages, and creates repair estimates.

• The notifications microservice checks the policyholder's communication preferences and sends personalized notifications including confirmations via mobile notifications or messaging.

The CRM didn't use any of these microservices directly. The CRM just noted that the claim was initialized. Each microservice decides upon itself if the information is relevant to its operations or not and acts accordingly without using any resources from the CRM. When fraud microservices finish their calculations, they send an asynchronous Platform Event back to the CRM with a computed risk assessment which is used by the event trigger for further processing of the claim.

Read-Optimized Materialized Views and Caching

Providing high-speed access to the CRM customer data in distributed applications is yet another challenge in enterprise microservice architecture and not to inundate the operational database of the CRM with the read requirements.

With the help of Change Data Capture streams, other microservices can have their own territorial and read-optimized materialized views of Salesforce data. When a customer-oriented e-commerce app wants to show real-time data, such as the account balance, available credit limit, or negotiated contract tier, it doesn’t query the APIs of the CRM even if the client is visiting it.

The moment an account executive changes the contract or discounts associated with the CRM account, Change Data Capture transmits that piece of information back to the event ingestion worker. Thanks to the processing of information done by the event ingestion worker, the e-commerce service’s in-memory cache is updated within milliseconds. As a result of that instantaneous refreshing, the storefront can read data in sub-millisecond time, more importantly, it can preserve its web availability regardless of the CRM parameters and avoid making thousand requests.

Strategic Summary: The Asynchronous Enterprise

Moving the main CRM products away from the company’s ERP systems and distributed microservices using Platform Events and Change Data Capture indicates an important step from sensitive and dependent systems towards an adaptive event-based business.

By substituting weak and dependent systems producing point-to-point communication with an adaptive and distributed event bus, companies free themselves from vulnerabilities caused by outdated technology and making user experience better. Collective transactions within Salesforce are no longer influenced by possible external delays, service outages, and failures of the network.

Platform Events gives businesses a clean semantic communication layer allowing them to create cross-system business processes without making them depend on databases’ structure. At the same time, Change Data Capture gives an opportunity to create a pipeline for replicating any information without the need of coding.

Advanced transport frameworks like Pub/Sub API in addition to strict engineering principles like keeping track of replayed states, successful message processing, and utilizing dead-letter queues help reconstruct Salesforce from a separate service into an integral part of a modern distributed business.

By combining event-driven architecture with state-of-the-art transport technologies, such as Pub/Sub API, and reinforcing the architecture through disciplined engineering methods, such as dead letter queuing, idempotent message processing, and stateful replay tracking, Salesforce becomes a robust business platform rather than just an isolated operational silo. Those who want to know how to apply these distributed principles can take the salesforce developer online course offered by OnlineITGuru and become an expert in Salesforce development.