When event-driven messaging is the right choice

Sometimes, application process messaging is best handled by APIs, but more organizations have learned that some of their key applications are better served with event-driven messaging. So where does it make sense to diverge from the classic API model?

In this Q&A, Massimo Pezzini, a research fellow at Gartner, explains where the line is drawn between API-based and event-driven messaging techniques -- including why architects might choose one method over the other and which approach suits each application.

As organizations integrate more hybrid resources, what sort of common messaging scenarios are you seeing?

Massimo Pezzini: With cloud integration, APIs are the prevailing mechanism.

But let's say you deploy your CRM, such as Salesforce, in the cloud. First, you need to upload data, such as customer data, into the new CRM system. This is typically a batch process because you can't call an API a million times to populate the customer database in the CRM. So batch data integration is used frequently.

We also see varied event-based scenarios where an application sends out a notification and all the applications [that integrate with it] receive the information in parallel. Instead of using the classic request-reply paradigm that [exists] when you use APIs, event technology lets you implement what is called a fire-and-forget mechanism: I send you a message and you receive it when you receive it.

A good example of these event processes are the notifications that you get on your mobile device. Occasionally, a notification pops up to tell you, for example, that your plane is delayed. This is classic event processing -- I send you a message and you do whatever you want with my message. But when I send you the message, I'm done. An API is more like 'I call you and I want you to do something for me.' I'm expecting a reply to that call right away.

The API mechanism still prevails, but we are also beginning to see more of this event-based mechanism.

Why is the API approach still more prevalent than event-driven messaging?

Pezzini: There are two reasons. The first reason is technical. Basically, you use the HTTP protocols GET and POST, so it's easy to implement. The second is more for developers. Request-reply is natural [and] intuitive. And the event mechanism is a bit trickier for [some] developers to get accustomed to.

If you are an operating system developer, for example, you are used to events. This is because every user mouse click is considered an event that is processed by the operating system. The same applies for the mobile app. Every click generates an event which is processed by the application itself. But for people developing administrative applications, the event mechanism is not very intuitive.

Could you illustrate when it makes more sense to use the event-driven messaging approach vs. the API approach, and vice versa?

Pezzini: Let's say you order a new CRM system and you want to make it possible for the salesperson who uses a Salesforce automation tool to call a customer and discuss product prices, product availability and shipment forecasts. But to do that, you need to connect your CRM system with your ERP system because things like product availability are likely stored in your ERP system.

Suppose the customer asks your salesperson, 'I ordered this product last week -- do you know when this is going to be shipped?' Using the CRM system, you want to request this piece of information from your ERP system.

This must be request-reply because you need to ask the ERP system to provide you with the shipment date for that particular product and order and receive [the answer] right away. That's a classic situation where the API request-reply scenario works very well.

But let's say we built mobile CRM applications for the salespeople. We want all our salespeople to know that until the end of a given week, products X, Y and Z will have an additional 10% discount if the customer buys more than 10 items. That information must be relayed as fast as possible to perhaps 10,000 salespeople via their mobile application. It cannot be implemented using a request-reply API [because] the CRM system will have to call the mobile application 10,000 times to tell the application about this promotion.

It is much easier in this case to send an event. This event will be propagated in parallel to all the 10,000 hypothetical salespeople in real time.

Let's also say that I'm a salesperson and my customer wants to know the shipment date for the particular order. I can try to do it, but if my ERP system is not up and running, I cannot answer the question -- the ERP system is not available, so I won't get a response. In event messaging, the message is not lost.

Or maybe I'm a salesperson and I'm in an airplane. I'm not connected to the network. When the notification about the new promotion comes up, I cannot receive it. When I land ... the event proxy mechanism allows me to retrieve events or messages even if they were sent when I was not available to get them.