Overview
Bizagi Kafka integration brings event driven integration capabilities to Bizagi. Instead of relying on synchronous request and response communication, Bizagi can participate in architectures where systems exchange information through streams of events.
This article introduces the concepts required to understand how Bizagi interacts with Apache Kafka. It provides the foundation for the specific guides on how Bizagi consumes and produces events.
Event driven architecture
What is an event?
An event represents a business occurrence or a change in state that is relevant to one or more systems. Examples of events include a customer placing an order, a payment being received, a support ticket being created, or an employee completing a training course.
Events typically contain information about what happened, when it happened, and any data required by systems that need to react to it.
What is event driven architecture?
Event-driven architecture is an integration style where systems communicate through events. When a business occurrence takes place, information about it is made available to other systems, which can react according to their needs.
This approach allows systems to exchange information without needing detailed knowledge about each other, creating a more flexible and scalable integration model.
Event driven architecture versus request and response integrations
Traditional integrations commonly follow a request-response model. In this approach, one system sends a request directly to another system and waits for a response before continuing its operation. Both systems must be available and able to communicate at the same time for the interaction to succeed.
Event-driven architectures follow a different approach. Instead of requesting information directly from another application, a system publishes an event describing something that occurred.
Consider the following example:
Request and response
1.A customer places an order.
2.The ordering system calls the inventory system and waits for its response.
3.The ordering system calls the billing system and waits for its response.
4.The ordering system calls the shipping system and waits for its response.
5.Each system must respond successfully before the process continues.
Event driven
1.A customer places an order.
2.At the same time:
a.The ordering system publishes an Order Created event.
b.The inventory system consumes the event and reserves stock.
c.The billing system consumes the event and generates an invoice.
d.The shipping system consumes the event and prepares the delivery.
In the event-driven model, the ordering system does not need to know which applications consume the event or how they process it. This reduces dependencies between systems and makes it easier to add, remove, or update applications without affecting existing integrations.
Apache Kafka
Why Apache Kafka?
Event-driven architectures require a platform that can distribute events between systems. While several technologies support event-based communication, Apache Kafka has become one of the most widely adopted event-streaming platforms for enterprise environments.
Kafka provides the core capabilities required to support event-driven communication between systems:
•Publish and subscribe to events: Applications can publish (write) and consume (read) events produced by other systems without requiring direct system-to-system connections.
•Store events reliably: Events remain available after they are published, allowing consumers to process information even if they are temporarily unavailable when the event occurs.
•Process event streams continuously: Applications can react to business events as they happen, enabling real-time integration scenarios.
For more detailed information, see the Apache Kafka documentation.
What this integration brings to Bizagi
This integration provides:
•Real-time updates, enabling information to be exchanged as events occur.
•High throughput, supporting large volumes of event-driven interactions.
•Scalability and extensibility, allowing integrations to grow as business needs evolve.
•Resiliency and fault tolerance, helping ensure events remain available for processing during temporary interruptions.
Kafka concepts
Topics
A topic is a channel where events are published. Producers send messages to topics and consumers read from them.
For example, an ordering system may publish events to a topic named orders. Applications interested in order-related events can subscribe to that topic.
Topics are not discovered automatically. Their names must be known and configured by both producers and consumers.
Publishing
Publishing is the act of sending an event to a Kafka topic.
When something relevant happens, such as a customer placing an order or a payment being received, the application can publish an event so that it becomes available to interested consumers.
For example, an ordering system can publish an Order Created event to the orders topic after a customer submits an order.
Subscribing
Subscribing is the act of listening to a topic to receive the events published to it.
Applications subscribe to the topics they are interested in and consume events as they become available.
For example, Bizagi can subscribe to the orders topic and consume Order Created events to start an order fulfillment process.
Producers
A producer is an application that publishes events to Kafka topics.
Bizagi can act as a producer by publishing process-related events for external systems to consume.
Consumers
A consumer is an application that reads and processes events from Kafka topics.
Bizagi can act as a consumer by reacting to incoming events and executing actions.
Events and Messages
An event represents a business occurrence, while a message is the data that carries information about that event.
In Kafka, events are exchanged and stored as messages.
Kafka does not enforce a specific structure. Messages can use formats such as JSON, XML, or plain text, but producers and consumers must agree on the format and contents of the message.
Consumer Group ID
A Consumer Group ID identifies a group of consumers that work together to process events from the same topic.
Consumers with the same Consumer Group ID share the processing of events. Consumers with different Consumer Group IDs receive events independently.
This value can be defined according to your integration requirements.
Offsets
Offsets define the position of a message within a topic.
Kafka uses offsets to track which messages a consumer has processed and where consumption should continue.
Message contract
A message contract is the agreement between producers and consumers on how a message should be structured and interpreted.
This agreement defines:
•Structure of the message
•Meaning of fields
•Expected content
Next steps
Now that you understand the main concepts behind event-driven architectures and Apache Kafka, you can continue with the following guides:
•Consuming events with Bizagi, to learn how Bizagi subscribes to Kafka topics and reacts to incoming events.
•Publishing events with Bizagi, to learn how Bizagi sends process-related events to Kafka topics for external systems to consume.
Last Updated 9/24/2026 7:13:59 PM