---
title: Event-Driven Architecture vs. Traditional Integration Patterns
slug: event-driven-architecture-vs-traditional-integration-patterns
createdAt: 2026-05-19T16:00:06.973Z
---

***

# Event-Driven Architecture vs. Traditional Integration Patterns

**Audience**: *This page is intended for readers without a technical background. It compares event-driven integration with traditional integration patterns and explains why Mantsu combines a UNS with an event broker.*

***

**Event-driven architecture** is the <u>*mechanism*</u>*:* the technical pattern where systems communicate by publishing and subscribing to events through a broker, rather than calling each other directly.

**UNS** is the <u>*design principle*</u> on top of that mechanism: the agreement that there is one shared namespace, with a consistent naming convention, where all producers publish and all consumers subscribe.

Both are required because neither is sufficient alone:

- A UNS without event-driven architecture is just a naming convention with no delivery infrastructure behind it. The data is sitting in the broker, but it remains inactive.
- Event-driven architecture without a UNS quickly becomes a mess: teams create topics with inconsistent names, duplicated data, and no shared understanding of what exists. The consequence is a distributed spaghetti architecture instead of a point-to-point one.

The UNS gives the event-driven broker a **purpose and a structure**. The event-driven broker gives the UNS a **working implementation**. Together they deliver the actual promise: any system can publish data once, any authorized consumer can find and subscribe to it, and no one needs to know who else is listening.

:::ExpandableHeading{isOpen="true"}
## Request/Response (REST APIs, OPC-UA)

In a request/response pattern, a consumer explicitly asks a producer for data at the moment it is needed. The consumer must know the producer's address, speak its protocol, and initiate every interaction.

- **Coupling:** tight. The consumer depends on the producer being available.
- **Latency:** data is only as fresh as the polling interval.
- **Scalability:** each new consumer adds load to the producer.
- **Typical use:** one-off queries, transactional operations (e.g. "create this order"), human-initiated lookups.
:::

:::ExpandableHeading{isOpen="true"}
## Database Integration (shared databases, interface tables)

Systems share data by reading from and writing to a common database. This is common in traditional ERP/MES integrations.

- **Coupling:** extreme. Schema changes in the shared database break all connected systems simultaneously.
- **Latency:** typically batch-oriented; data is hours or days old.
- **Scalability:** the shared database becomes a bottleneck and a single point of failure.
- **Typical use:** batch reporting, overnight data synchronisation
:::

::::ExpandableHeading{isOpen="true"}
## Event-Driven / Publish-Subscribe

Producers publish events to a broker the moment something happens. Consumers subscribe to the topics they care about and receive events in real time, independently of all other consumers. Producers have no knowledge of who is consuming their data.

- **Coupling:** none between producers and consumers. Both depend only on the broker and the agreed topic schema.
- **Latency:** near real-time; events are delivered within milliseconds of being produced.
- **Scalability:** adding consumers has no impact on producers. The broker handles fan-out.
- **Typical use:** live operational data, cross-system business event propagation, streaming analytics.

:::hint{type="info"}
Event-driven architecture does not replace request/response for all use cases. Transactional operations (e.g. submitting a production order from the ERP to the MES) remain well-suited to REST APIs. The UNS complements, rather than eliminates, these patterns.
:::
::::

# Comparison Summary

| ***Dimension***                        | ***Polling / REST*** | ***Shared Database*** | ***Event-Driven (UNS)*** |
| -------------------------------------- | -------------------- | --------------------- | ------------------------ |
| Coupling                               | Medium               | High                  | Low                      |
| Data freshness                         | Interval-bound       | Batch                 | Real-time                |
| Scalability                            | Limited              | Poor                  | High                     |
| Fault tolerance                        | Producer dependency  | DB dependency         | Broker resilience        |
| Discoverability                        | Low                  | Medium                | High                     |
| Suitable for OT data                   | Partial              | No                    | Yes                      |
| Suitable for business events (IT data) | Yes                  | Partial               | Yes                      |

***

**Summary**: *Event-driven architecture is the delivery mechanism, the UNS is the design principle on top of it. Combined, any system publishes data once and any authorized consumer can find and subscribe to it, replacing fragile point-to-point integrations.*