Event-Driven Architecture vs. Traditional Integration Patterns

event driven architecture is the mechanism the technical pattern where systems communicate by publishing and subscribing to events through a broker, rather than calling each other directly uns is the design principle 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 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 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 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 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