Event driven architecture can be contrasted with one oriented around the database. There are a handful of challenges which this more traditional architecture presents with the expectation of contemporary users. One of the most obvious is that it is a synchronous transaction where a single resource is the bottleneck for the entire flow of the application.
A slow database query can block all other queries and so degrade the experience of all other users. This basically places all requests on the same plane, without any prioritization or discrimination between them. They all have to be executed on demand and against the same resource.
Perhaps a different paradigm for thinking about applications is centered around the concept of an event.
An event is a significant change of state to an object and any specific data relevant to it.
Events can come from a variety of sources -- a user, a sensor, an alert, or the application itself. Based on the complexity there are a couple basic formats for processing events.
Two kinds of event architecture: Broker vs Mediatory Toplogies
Source --> Queue --> Consumer
Source --> Processor --> Queue --> Consumer