What is Event-Driven Architecture?

In theory:

Event-driven architecture (EDA) is a software design pattern that enables an organization to detect “events” or important business moments (such as a transaction, site visit, shopping cart abandonment, etc.) and act on them in real time or near real time. This pattern replaces the traditional “request/response” architecture where services would have to wait for a reply before they could move onto the next task. The flow of event-driven architecture is run by events, and it is designed to respond to them or carry out some action in response to an event.

Event-driven architecture is often referred to as “asynchronous” communication. This means that the sender and recipient don’t have to wait for each other to move onto their next task. Systems are not dependent on that one message. For instance, a telephone call is considered synchronous or more along the lines of the traditional “request/response” architecture. Someone calls you and asks you to do something, the requestor waits while the responder completes the task, and then both parties hang up. An asynchronous example would be text messaging. You send a message and in some cases, you don't even know who you are sending it to or if anyone’s listening, but you are not waiting for a response.

In practice:

Instead of acting based on intent, we are acting as a reaction.

How it fits in our system

We can use EDA in many part of our application but in order to communicate the point effectively we are going to use it in a very narrow use case.

In the Cart Microservice we save the item in the cart and as part of the same operation we also keep the Redis cache in sync with CosmosDB. This is generally considered an anti-pattern because the two operations are not atomic. This means that if the Redis update fails, the CosmosDB update will still go through and Redis will return outdated data also known as dirty reads.

We are going to fix that by introducing a CosmosDB feature called the Change Feed.