What is event driven architecture?

Your thoughts?

|

Event driven architecture involves using messaging frameworks like Kafka or MQ.

When listener is down, messages accumulate in a particular topic.

This differs from the request/response model of synchronous REST APIs.

REST can be good when you need a response right away..like with authentication

Logging, metrics, "fire and forget" is best for event driven architecture.

Asynchronous behavior and decoupled services are key characteristics of event driven architecture.

Event driven architecture can offer a performance boost because applications receive messages when they are actually needed instead of constantly asking or "polling" services for information like with a synchronous REST API.

When considering REST APIs, there are also advantages to event driven architecture such as avoiding unnecessary networking delays, services being down, paginated responses, etc.

Potential downside of event driven architecture is that it can introduce a single point of failure. Like if you have a bunch of microservices communicating over Kafka, and if your Kafka cluster goes down...you are screwed.

|

Event driven architecture revolves around the publisher/subscriber or producer/consumer model where certain services send events to other services which listen for events.

This "push" based approach is largely considered better to more traditional synchronous architecture seen with RESTful APIs where a collection of services implement a request/response model to communication.

Event driven architecture goes hand in hand with microservice based architecture. A microservice is an easily maintainable application that can be independently deployed and communicates with other microservices to collectively represent a solution or experience for the end user.

Event driven architecture is considered "better" for most use cases because it's more efficient than the request/response model. Individual services can be easily scaled and there is a HUGE performance improvement to avoiding delayed network responses AND "pushing" data to systems only when they need it. With traditional REST, a "polling" mechanism is constantly "asking" another service for information. This leads to unnecessary network calls. It's much easier with an event driven approach because "listening" applications can receive information only when it's ready to be consumed. This saves a bunch of network calls and allows different microservices to more independently scale without blocking other applications.

|

Here is what I don't understand about event driven architecture and REST API. You can just expose a POST endpoint and "send events" to a server that way...

Seems like a lot of buzz word talk to dress up different network protocols to me :)

|

Event driven architecture is best understood by thinking "push" vs "pull". Think about a traditional REST API where you have an endpoint like GET /something. You hit an endpoint and you get a response.

Now think of a situation where you get a push notification or a message in your chat app or inbox. This is event based as you get an update instead of "polling" or asking for it.

So event driven architecture involves designing software so the communication between systems or services is "event based" aka push based. Nothing needs to be invoked for something to happen, rather it happens based on receiving an event.

An event can be a detailed message with a payload (similar to a response from a REST API) or just a message indicating something happened.

|

Event driven architecture is the modern way of developing scalable (enterprise) software solutions. It coincides with the popularized microservice based approach to software development seen today.

An event is used to communicate a change in state. An event is produced from application A and consumed by application B (or B and C, or B and C and ...).

The main advantage of event based architecture is that multiple applications or services can simultaneously listen to or "subscribe" to the same event. When thinking about traditional REST APIs where you call or poll a service, this is a huge advantage.

A popular analogy I saw was someone asking a waiter when their meal was ready. How annoying is it if the customer is repeatedly asking the waiter "is it ready?, is it ready?". Alternatively, it's much more efficient when the waiter simply notifies the customer when their order is ready. The customer doesn't have to exert so much effort and can react at the moment the food is ready...

This, in a nutshell, is what event driven architecture is all about and why it's so popular today with enterprise software development...

|

i think its basically kafka and pub/sub type development.