Photo by Sigmund on Unsplash

Event-Driven Architecture (EDA) is a trending software architecture pattern nowadays. Many organizations and systems adopt this pattern due to its scalability and flexibility. Let’s discuss the basics of events, event sourcing & CQRS, streaming, logging & monitoring and implementation strategies through this article.

Events

This is the cornerstone of event-driven architecture. The EDA has evolved from microservice architecture while it replaces legacy architectures such as monolith and SOA. The classic communication between services is command and query. The services either send commands or queries for data.

💡 Treating microservices as composable building blocks is key, and it’s made easier with a tool like Bit which allows your teams to independently publish, version, document, test, and share individual components such as functions, UI elements, or data models, that can be reused across multiple microservices.

Learn more here:

Command and Query

The main characteristics of this communication are

There are 3 main problems with command and query,

• Performance: Due to the synchronous nature
• Coupling: The calling service calls a specific service
• Scalability: The calling service calls a single instance of a service

These drawbacks can be overcome by using events. Event indicates that something happened in the system. The main features of event are

• Asynchronous
• Calling service has no idea who handles the event
• Never returns a response
• Something happened

There are two types of event data, complete and pointer.

Complete is the better approach since it makes the event completely autonomous while pointer can be used for large sets of data.