Event-driven integration: what it is and when you need it

A new order arrives in the e-shop. The warehouse needs it to pick and pack, invoicing needs it to issue the invoice, the CRM needs it to update the customer’s history, and next year the loyalty programme will need it too. The usual first version is a single integration that calls all of these systems one after the other. It works until one of them is slow or down, and then the whole chain stops, including the parts that had nothing to do with the problem.

Event-driven integration is a different way of wiring systems together: the e-shop announces that something happened, and every system that cares reacts on its own. This guide explains the core ideas, the guarantees you can and can’t rely on, when the approach pays off and when it doesn’t, and how to compare the tools.

Events, commands and why the difference matters

Two kinds of messages look alike on the wire but mean different things:

A command asks a specific system to do something: “create sales order C-1042 in the ERP”. The sender knows the receiver and usually cares about the result.
An event states a fact about the past: “order 58213 was created”. The sender doesn’t know or care who listens. Events are named in the past tense for that reason.

The shift from commands to events is what decouples systems. The e-shop no longer needs to know that a warehouse system exists. Adding the loyalty programme becomes “subscribe to order.created”, not “change the e-shop integration and retest everything”.

A good event carries enough to be useful on its own: an event ID, the event type, a timestamp, the business key (order number, customer ID such as C-1042) and either the relevant data or a link to fetch it.

{
  "eventId": "7f1c2e9a-4b1d-4c55-9a51-2d1f0b7c9e10",
  "type": "order.created",
  "occurredAt": "2026-10-23T09:14:02Z",
  "orderId": "58213",
  "customerId": "C-1042",
  "total": 184.50,
  "currency": "EUR",
  "lines": [{ "sku": "OL-500", "qty": 2 }]
}

The building blocks

Publish/subscribe

In pub/sub, producers publish events to a named channel and any number of subscribers receive a copy. The producer publishes once; the broker takes care of fan-out. That is exactly the order example: one order.created event, three or four independent consumers.

Topics and queues

The two classic channel types:

A queue delivers each message to one consumer. Several workers can read the same queue to share the load, but each message is processed once. Good for distributing work.
A topic delivers each message to every subscription. Good for broadcasting facts.

Most modern brokers blur the line. In Kafka, consumer groups share a topic’s partitions; in Apache Pulsar, each subscription on a topic gets every message, and consumers within one subscription can share the load. The concept to hold on to is: one copy per interested system, shared among that system’s workers.

The broker

Producers and consumers never talk to each other directly. A broker stores events until each subscription has processed them. This is what gives you resilience: if the CRM is down for an hour, its events wait, and the warehouse and invoicing carry on as normal.

The guarantees you get (and the ones you don’t)

At-least-once delivery

Almost every practical setup delivers at least once. A consumer processes a message and then acknowledges it. If it crashes between the two, the broker redelivers. So consumers will occasionally see the same event twice. “Exactly-once” exists in narrow forms inside some platforms, but across a broker and an ERP it is not something you should count on.

Idempotent consumers

The answer to at-least-once delivery is to make every consumer idempotent: processing the same event twice has the same effect as processing it once. Common techniques:

Store processed event IDs and skip ones you have seen.
Use the business key as a natural guard: before creating sales order for web order 58213, check whether it exists.
Prefer “set” operations (“stock for OL-500 is 12”) over “add” operations (“add 2 to stock”).

Ordering

Ordering is usually guaranteed only within a partition or key, not across a whole topic, and parallel consumers can process messages out of order anyway. If order matters (an order.cancelled must not be processed before its order.created), route related events by the same key, such as the order number, and design consumers to tolerate the occasional surprise, for example by checking the current state before acting.

Failed messages

Some messages will fail every time: a missing customer, a malformed field, a product the ERP doesn’t know. Without a plan, these poison messages block a subscription or get retried forever. The standard answer is a limited number of retries followed by a dead-letter topic or queue, where someone can inspect, fix and replay them. We build exactly that in Handling poison messages with retries and dead-letter topics in Boomi Event Streams.

When event-driven is the right choice

It pays off when several of these are true:

One fact, many interested systems. An order, a new customer, a price change that three or more systems need.
Systems with different availability. A cloud e-shop that never sleeps and an on-premises ERP that is backed up every night.
Spiky volume. Black Friday traffic can be absorbed by the broker and processed at the pace the ERP can handle.
Systems that come and go. New consumers can be added without touching the producer.
Near real time matters, but the producer doesn’t need to wait for the consumers.

When something else is better

Event-driven is not a default. Other styles are often simpler:

Request-reply is better when the caller needs an answer now: “is this item in stock?”, “what is this customer’s balance?”. Don’t build an event round-trip for a question. (See Sync vs async integration in Boomi for the trade-offs.)
Batch is better when the data is naturally periodic and nobody benefits from seconds of latency: a nightly export of the day’s invoices to the accounting firm, or monthly loads into a data warehouse.
A simple point-to-point flow is fine when there is exactly one consumer and that is unlikely to change.

Many real landscapes use all three: request-reply for queries, events for state changes, batch for reporting.

Common mistakes

Events that are really commands. An event called createInvoiceInErp couples the producer to one consumer again. Publish order.created and let invoicing decide what to do.
Assuming exactly-once. The first duplicate invoice usually ends this belief. Design for duplicates from day one.
Huge or tiny events. Events with the full ERP document are hard to evolve; events with only an ID force every consumer to call back to the source, which then becomes the bottleneck. Include what most consumers need.
No schema discipline. Version event formats and add fields rather than renaming or removing them. A shared event format works best when it follows a canonical model (see A canonical data model in Boomi).
No plan for failures. Without dead-lettering and monitoring of backlogs, problems are discovered by customers.
Using a broker as a database. Retention is for recovery and replay, not for answering business queries.

How to compare tools

Before shortlisting products, answer these questions:

What volume and latency do you need? Hundreds of orders a day and millions of telemetry events a minute are different problems with different tools.
Do you need replay? Log-based brokers keep events for a retention period so consumers can re-read history. Classic queues delete messages once consumed.
Where do producers and consumers run? A single cloud, several clouds or on-premises systems such as an ERP behind a firewall.
Who writes the producers and consumers? Developers writing code against client libraries, or an integration team building flows in a platform with connectors to the ERP and CRM?
Managed or self-hosted? Running a broker cluster well takes skills and time. A managed service shifts that work to the vendor.
What about failures and monitoring? Check how retries, dead-lettering, backlog alerts and message inspection work in practice, not just whether they exist.

Tools in this space

These are the products we encounter most often, in alphabetical order.

Apache Kafka / Confluent. The de facto standard for high-volume event streaming, with a huge ecosystem of connectors and stream-processing tools. Confluent offers a managed cloud service and enterprise features on top of open-source Kafka. Powerful, but self-managing it takes real expertise.
AWS EventBridge / SNS + SQS. On AWS, EventBridge routes events between services and SaaS sources with rule-based filtering, while SNS (fan-out) combined with SQS (queues) is a long-standing, simple pub/sub pattern. A natural fit when most of your systems already run on AWS.
Azure Service Bus / Event Grid. Service Bus is a mature enterprise message broker with queues, topics, sessions for ordering and built-in dead-letter queues; Event Grid is a lightweight event routing service. Strong for organisations already on Azure.
Boomi Event Streams. A managed event streaming service, built on Apache Pulsar, that is part of the Boomi platform. Topics and subscriptions are managed alongside your integration processes, and processes produce and consume events through a dedicated connector. It fits best when the systems publishing and reacting to events are already connected through Boomi Integration, so the event broker and the ERP or CRM logic live in the same place.
RabbitMQ. A widely used open-source message broker with flexible routing (exchanges, queues, bindings). Easy to start with and well understood by developers; often used for work queues and service-to-service messaging.
Solace. An event broker available as hardware, software and cloud service, known for its event mesh across clouds and on-premises sites and its support for many protocols. Common in finance, manufacturing and other latency-sensitive industries.

If you already use one of these platforms for integration or hosting, start your evaluation there.

Where to go next

Two practical articles show the patterns from this guide in Boomi:

Publish once, consume many: pub/sub with Boomi Event Streams: one order.created event for warehouse, invoicing and CRM.
Handling poison messages with retries and dead-letter topics in Boomi Event Streams: retries, dead-letter topics and replay after a fix.