Understand Event-Driven Software Architecture

Learning Objectives

After completing this unit, you’ll be able to:
  • List the components of event-based software architecture.
  • Explain the benefits of an event-driven software architecture.
  • Describe use cases for the Platform Events feature.
  • Describe the characteristics of a platform event.

Before You Start This Module

We know you're eager to get started! But before you settle in to work through this module, you should be familiar with some concepts to be able to complete this module. 

This module shows you how you can publish platform events using Apex, REST API, flows, and processes. Also, you can subscribe to platform events using Apex triggers, flows, processes, a Lightning component, and a CometD-based tool. To be able to understand this module, you should be familiar with at least one of these technologies. To be able to perform the hands-on challenge in this module, you should have knowledge of Apex triggers. Here is a list of a trail and modules you can take to learn Apex.

Also, familiarity with the concepts of Streaming API is helpful for this module. If you haven’t already, complete the Lightning Platform API Basics modulebefore you work on this module.

Understand Event-Driven Software Architecture

Has your order system shipped a package? Do your printer cartridges need replacing? Whatever you want to be notified about, the Salesforce enterprise messaging platform provides the delivery of secure and scalable custom notifications within Salesforce and from external sources. With platform events, you can monitor your systems and communicate changes to other systems.

The paradigm of event-based communication revolves around a publisher-subscriber model—a sender broadcasts a message that one or more receivers capture. It’s like radio transmission—a transmitter tower broadcasts a radio signal, and receivers get the signal if they’re tuned to the right frequency.

Much like radio transmission, event-based communication flows from the sender to the receiver. Events get sent whether or not receivers are listening, and receivers don’t acknowledge it when they receive an event. Event-based communication takes place in real-time—or, more accurately, in near-real time. Radio waves travel at the speed of light, but event-based software and hardware systems typically have some latencies. 

In the Lightning Platform API Basics module, we use the analogy of radar on a pirate’s ship to represent event detection. This analogy works well for the streaming of PushTopic events, which are based on changes in Salesforce records. That communication model requires only a subscriber. But with platform events, there are two parties to the communication: a sender and a receiver. They are two of the components of an event-driven architecture.

Components of Event-Driven Systems

Before we go any further, let’s define some terms.

A change in state that is meaningful in a business process. For example, placement of a purchase order is a meaningful event, because the order fulfillment center expects to receive a notification before processing an order.

Event message
A message that contains data about the event. Also known as an event notification. For example, an event message can be a notification about an order placement containing information about the order.

Event producer
The publisher of an event message. For example, an order placement app.

Event channel
A stream of events on which an event producer sends event messages and event consumers read those messages. For platform events, the channel is for one platform event and groups all event messages for that platform event.

Event consumer
A subscriber to a channel that receives messages from the channel. For example, an order fulfillment app that is notified of new orders.

Event bus
A communication and storage service that enables event streaming using the publish-subscribe model. The event bus enables the retrieval of stored event messages at any time during the retention window.

The following diagram illustrates an event-based software architecture.

A diagram showing components of event-based systems: event producers, which feed information into the event bus, which sends messages to the event consumers
Unlike request-response communication models, software architecture built on an event-driven model decouples event producers from event consumers, thereby simplifying the communication model in connected systems. No requests need to be made to a server to obtain information about a certain state. Instead, a system subscribes to an event channel and is notified whenever new states occur. Any number of consumers can receive and react to the same events. When an event occurs, systems obtain this information and can react to it in near-real time. Systems that send events and others that receive the events don’t have dependencies on each other, except for the semantics of the message content.

The Salesforce enterprise messaging platform offers the benefits of event-driven software architecture. Platform events are the event messages that your apps send and receive. They simplify the process of communicating changes and responding to them without requiring you to write complex logic. Publishers and subscribers communicate with each other through platform events. One or more subscribers can listen to the same event and carry out actions.

Say a news agency called Cloud News sends events to subscribed clients with the latest breaking news about traffic and road conditions in a mountain retreat destination. The contents of those events are not just the news items themselves but also related details such as whether a piece of news is urgent, and the location of the incident. Subscribers can receive these events and determine what actions to take based on the urgency of the news.

All this sounds good, but what are some real-world cases when you can use platform events? Of course, the use of platform events isn’t restricted to a news agency. Following are a few useful applications.

Examples of When to Use Platform Events

Let’s take a look at a few business scenarios that use platform events. In these scenarios, Salesforce and external systems communicate through platform event messages. In the first scenario, an app in Salesforce notifies external order fulfillment apps of a product shipment order. In the second scenario, an external product app notifies Salesforce of merchandise returns. The last scenario shows how event messages are used within Salesforce by using triggers.

Platform to External App: Order Fulfillment in a Vendor App

When an opportunity closes as won in Salesforce, your company has won a deal with a customer. Let’s say you use vendors to ship products associated with an opportunity. Each vendor has an external app that processes shipment orders for specific products. The external app listens to platform events. When an opportunity closes, a trigger, which is part of a product order app in Salesforce, fires and publishes a platform event message. Each vendor app is notified of the event. The vendor responsible for shipping the specific product creates the shipment.

In this diagram, a product order app publishes an order event to an event bus. Various vendor apps subscribe to the event bus and receive the event.

External App to Platform App: Process Merchandise Returns in Salesforce

Let’s say someone wants to return purchased merchandise to a vendor. An external system sends merchandise return requests to Salesforce for processing. The external system publishes a platform event to alert Salesforce to the merchandise return. An event listener (a trigger) in Salesforce receives the event and performs some actions. For example, the trigger might alert the sales representative to the return, and send a confirmation email to the customer.

An external vendor app publishes a platform event message for a merchandise return request. In Salesforce, a trigger subscribes to the event bus and receives the event.

Platform to Platform: Reassign Lead Records

When a lead is assigned in Salesforce, a lead trigger fires and checks open opportunities and cases related to the lead owner. Based on the related records, the trigger publishes an event that is received by a Salesforce app. Based on the event information, the app reassigns the lead and creates a Chatter post.

In this scenario, you can perform the same actions using other Salesforce features, such as Process Builder or flows. But by using platform events, you benefit from an event-based programming model and a standard way of programming across your apps.

In this diagram, an app in Salesforce publishes a platform event. A trigger subscribes to this event channel and receives the event.

Platform Event Characteristics

Now that you have an idea of when to use platform events, let’s dive deeper into their components and characteristics.

You define the custom data that platform events contain. Just like custom objects, you define platform events in Salesforce. You create a platform event definition by giving it a name and adding custom fields. Here is a sample definition of custom fields for a news event for the Cloud News agency.

Field Label/Name Field API Name Field Type
Location Location__c Text
Length: 100
Urgent Urgent__c Checkbox
News Content News_Content__c Text Area (Long)

Platform Events and Salesforce Objects

A platform event is a special kind of Salesforce entity, similar in many ways to a Salesforce object. An event message is an instance of a platform event, similar to how a record is an instance of a Salesforce object. Unlike with records, you can’t update or delete event messages or view them in the Salesforce user interface.

You can set read and create permissions for platform events. You grant permissions to users in profiles or in permission sets.

Using Platform Events in Native and External Apps

Platform events enable the flow of event messages within Salesforce and to or from external apps. Apps on the Salesforce platform use an Apex method to publish events and an Apex trigger or the empApi Lightning component to consume events. As an alternative to code, you can publish events with declarative tools, such as Process Builder and Flow Builder. External apps publish events using the sObject API and consume events using CometD. As you can see, there is a lot of flexibility in how you choose to use Platform Events!

Differences Between Platform Events and Other Streaming Events

What about other streaming events? Other events include PushTopic and generic events. With PushTopic events, clients receive messages about changes in Salesforce records based on a predefined query. With generic events, you can send and receive arbitrary message content (payloads) not necessarily tied to Salesforce records. Platform events are similar to generic events but offer more powerful customization. With platform events, you can publish any custom data. You define the schema of event data at a granular level as typed fields. Also, you can use platform events in native Salesforce platform apps and external apps alike. Use platform events in the following cases:

  • To send and receive custom event data with a predefined schema
  • To publish or subscribe to events in Apex
  • For the flexibility of publishing and processing events on and off the Salesforce platform

This table compares the features of generic events and platform events.

Feature Generic Event Platform Event
Define event schema as typed fields
Check mark
Include user-defined payloads Check mark Check mark
Publish events via one or more APIs Check mark Check mark
Publish events via Apex
Check mark
Subscribe via CometD Check mark Check mark
Subscribe via Apex triggers
Check mark
Publish declaratively using Process Builder and Flow Builder
Check mark

For a comparison of more event types, see Streaming Event Features in the Streaming API Developer Guide.

In the next unit, we go over defining a platform event and publishing events.

Keep learning for
Sign up for an account to continue.
What’s in it for you?
  • Get personalized recommendations for your career goals
  • Practice your skills with hands-on challenges and quizzes
  • Track and share your progress with employers
  • Connect to mentorship and career opportunities