The previous sections highlighted traditional API patterns where Developer X writes code on- or off-platform that then calls a REST- or XML-based API to perform a specific operation against your application's objects or services. That API then returns a response immediately.

While this is an easy model to understand, it can have its downsides in terms of performance because the client is holding open connections and valuable resources while it waits for the API to return. Additionally, it also does not permit the backend to queue requests as needed. From a software design perspective, the tight coupling between Developer X's client code and a specific API code inhibits the ability to refine the overall architecture quickly as each point of integration needs to be modified, for example, if a totally new API needs to be introduced. This pattern is known as point-to-point integration. An alternative to this is known as pub-sub (publish and subscribe). 

The pub-sub pattern can also be regarded as loosely coupled API integration. In this case, a message bus is required to keep track of messages that allow your application to declare messages that Developer X can respond to or send for your application to respond to. A message bus can support many different messages, known as message types. In this regard, the message type is an abstraction over the operation and allows for the handling of the operation to change without changing the client code, hence loosely coupled. The following diagram illustrates several clients sending events to the event bus to be received by one or more handlers, depending on the type of message:

In the diagram, there are three clients, each sending (or publishing) events to the event bus. When the event bus receives these events, it dispatches them to handlers who have subscribed to each of the events. In this case, the client application code is unaware of how the events are eventually handled, hence the term loosely coupled. 

In the Lightning Platform, the pub-sub concept is exposed through the platform events feature. Defining message types is achieved by creating a platform event object, much like you do with a Custom Object, where the fields defined describe the data to be contained in the message, as shown in the following screenshot:

While you can use platform events for your application's internal asynchronous processing needs (something that we will cover in the next chapter), you can also consider a platform event object as effectively disclosing an asynchronous API for your application. In this case, depending on the intent, Developer X would either send events (messages) to your application code or receive events from your application code asynchronously. The Lightning Platform provides a number of programmatic and declarative tool options for sending and receiving events via on-platform APIs, such as those in Apex and REST APIs for off-platform scenarios. In this chapter and the next, we will explore two examples highlighting this pattern further. Meanwhile, the Platform Events Developers Guide can be found at https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm.