Event-driven architecture
1. Event-driven architecture
Many applications built using microservices will benefit from an event-driven architecture. Before we discuss event-driven architecture, we must understand events. An event is a record of something that has happened. Examples of events are an employee logging in to an application or a product being added to a shopping cart. That definition may seem obvious. However, when we are discussing event-driven architectures, there are other important attributes of events. First, an event is typically treated as an immutable fact. It's an historical record of an occurrence, and it should not be modified or deleted. Second, an event can be generated even if it's never consumed. Many applications that produce events don't know whether the events they generate are ever consumed. Third, an event can be persisted indefinitely, and can be consumed as many times as necessary. A single event can be consumed by many services, allowing event processing to occur in parallel. As discussed earlier, the "spider web" of point-to-point communication between microservices can be a challenge. Each service must know how to communicate with all downstream services. Point-to-point communication tends to introduce coupling between the microservices. An event-driven architecture inserts an event intermediary between the services. When a service acts as an event producer, it sends events to the intermediary. It isn't necessary for the service to know anything about the services that are consuming the events. A service can also act as an event consumer, receiving events from the intermediary. Event consumers understand how to handle an event. The consumers do not have to know any details about the event producer.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.