# Event-Driven Architecture

> Source: https://netray.co/glossary/event-driven-architecture
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Glossary

## Short answer

Event-driven architecture is a design where systems publish events, such as a goods receipt posted, and other systems subscribe and react to them. It replaces constant polling and tight point-to-point calls with loosely coupled, asynchronous messages.

## Aliases

- EDA
- event driven integration
- publish subscribe
- event streaming

## Category

integration

## Full Definition

An event is a fact that something happened: an order was released, a quality hold was set, a machine stopped. A producer publishes the event to a broker, and any number of consumers subscribe. The producer does not know who listens, which keeps systems loosely coupled. Brokers include message queues such as RabbitMQ, log-based streaming platforms such as Kafka, and cloud services such as Azure Service Bus or AWS SNS and SQS.

Compared with polling, events cut latency and load. Instead of a nightly job asking the ERP what changed, the ERP or a change data capture tool emits an event when a row changes. A consumer then updates a dashboard, sends an alert or starts a workflow within seconds. The cost is operational: you must design for duplicate delivery, out-of-order events, retries and dead-letter queues.

ERPs vary in how they emit events. Infor SyteLine has an event system and sends BODs through ION. NetSuite offers user event scripts and SuiteScript hooks. SAP provides business events and IDocs. Where the ERP cannot emit events, database change capture or a polling adapter can synthesize them.

This model suits AI agents well. An agent that wakes on a 'purchase order past due' event can look up the supplier, draft an expedite note and ask a buyer to approve it, instead of someone watching a report. The agent should remain read-only or approval-gated for anything that writes back to the ERP.

## Why It Matters

- Events give near real-time reactions without hammering the ERP with polling queries.
- Loose coupling lets teams add a new consumer, such as an AI agent, without changing the ERP.
- Delivery guarantees, ordering and idempotency must be designed, or duplicates will corrupt downstream data.
- It is a practical trigger layer for proactive alerts and agent workflows on top of an ERP.

## In Practice

A plant wants a supervisor alerted when a work order is held for quality. The ERP's hold action emits an event to a broker. One consumer posts to the supervisor's chat channel, another updates the schedule board. During testing the same event arrives twice after a retry, so the consumers store the event ID and ignore repeats, which keeps the alert from firing twice.

## Faq

### What is the difference between a webhook and an event broker?

**Answer:** A webhook is a single HTTP callback to one URL. A broker receives events and delivers them to many subscribers with queuing and retry.

### Do I need Kafka for event-driven integration?

**Answer:** Not necessarily. A simple message queue is enough for many plants. Kafka suits high volume and replay needs.

### What if my ERP cannot publish events?

**Answer:** Use database change capture or a scheduled adapter that detects changes and publishes events on the ERP's behalf.

### How do AI agents fit with events?

**Answer:** Events can wake an agent to investigate and propose an action, with a human approving anything that changes ERP data.

## Search terms

event-driven architecture, event driven integration ERP, publish subscribe pattern, Kafka ERP integration, message queue vs event stream, ERP events AI agent, event driven vs polling, idempotent consumers

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json