Werner Vogels, CTO of Amazon.com, said it loud and clear in his opening keynote at AWS Re:Invent 2022: “The world is asynchronous. The world is event-driven”.
As a global conference about the Cloud, Re:Invent is a crucial annual milestone for selling ideas, showing technology directions and presenting innovations. That is precisely what Dr Vogels did by promoting this asynchronous architecture, the basis of a new generation of cloud computing.
But do you know exactly what an event-driven architecture consists of?
How it differs from an API-driven architecture? Its benefits?
Let us guide you through this asynchronous world!
TABLE OF CONTENTS
- Event-driven architecture: a new approach
- API-driven architecture vs. event-driven architecture
- Challenges of API-driven architecture
- The benefits of event-driven architecture in the face of these challenges
Event-driven architecture: a new approach
When it comes to modern application development, an “event-drive architecture” – an architecture driven by events – is becoming more and more the norm, because it makes it much easier to build solutions on the Cloud.
It lets you decouple your services, which:
- increases your developers’ productivity,
- makes applications easier to debug,
- removes the bottleneck that occurs when features span different teams,
- allows teams to move forward more independently.
In an event-driven architecture, the way you think about how an application works changes. You see it as a system that reacts to events coming from your application, but also from outside it.
In this approach, you focus on the system’s interaction with its environment as the transmission of events. The application receives and creates events. The application’s inputs and the application’s outputs also act as events.
API-driven architecture vs. event-driven architecture
In API-driven architecture, the components of an application communicate through API calls. The client sends a request and waits for a response before carrying out the next task.
In an event-driven architecture, the client generates an event and can immediately move on to its next task. Different parts of the application then respond to the event as needed.
Challenges of API-driven architecture
When starting to build a new application, many developers default to an API-driven architecture. It can tightly integrate components, and those components communicate through synchronous calls.
Although an API driven approach is often easier to start with, it can become difficult as your application grows more complex. Here is an example in the context of an e-commerce application.
Tight coordination between microservices
In a typical e-commerce application that uses a synchronous API, the client makes a request to place an order and the order service sends the request downstream to a billing service. If it succeeds, the order service replies with a success message or a confirmation number.
In this initial phase, it is a direct connection between the two services. The challenge arises when you add more services that integrate with the order service.
If you add a fulfilment service and a forecasting service, the order service has more responsibilities and more complexity. The order service has to know how to call each service’s API, from the API call structure to the API’s retry semantics.
Error handling and retries
Let us say you add new downstream services for order fulfilment and shipping to the e-commerce application.
In the best case, everything works as planned: the order service triggers billing and the payment systems and updates the forecasts. Once the payment has gone through, that triggers fulfilment and packing of the order, then informs the shipping service of the tracking details.
However, if the distribution centre cannot find the product because it is out of stock, the distribution service may have to alert the billing service, then cancel the payment or issue a refund.
If fulfilment fails, the system that triggers shipping can also fail. The forecasts also have to be updated to reflect the change. This corrective workflow only sets out to resolve one of the many potential “unhappy paths” that can arise in this API-based e-commerce application.
Tight coordination between development teams
In a synchronously integrated application, the teams have to coordinate every new service added to the application. That can slow down each development team’s ability to release new features.
Imagine: your team is working on the payment service, and nobody tells you that another team has added a new rewards service. What happens if the fulfilment service errors?
Your payment team receives a message and you cancel the payment, but you may not know who handles the retries and the error logic. If the rewards service changes provider and has a new API, and does not tell your team, you may not be aware of the new service.
In the end, it can be difficult to coordinate these orchestrations and workflows as the systems become more complex and management adds more services. That is one of the reasons why it can be worth migrating to an event-driven architecture.
The benefits of event-driven architecture in the face of these challenges
Event-driven architecture can help resolve the problems of tight microservice coordination, error handling and retries, and coordination between development teams.
Tight coordination between microservices
In an event-driven architecture, the publisher emits an event, which is acknowledged by the event bus. The event bus routes the events to the subscribers, which process the events with self-contained business logic. There is no direct communication between publishers and subscribers.
Decoupled applications allow teams to act more independently.
For example, with API-based integration, if your team wants to be told about a change that has happened in another team’s microservice, you may have to ask that team to make an API call to your service.
As a result, you may have to take account of authentication and of coordination with the other team on the structure of the API call. This causes back and forth between the teams, which slows down development time. With an event-driven application, you can subscribe to the events sent from your microservice and the event bus (for example, Amazon EventBridge ) takes care of routing the event and handling authentication.
Error handling and retries
Another reason to migrate to an event-based architecture is to handle unpredictable traffic. E-commerce websites such as Amazon.com have varying amounts of traffic depending on the day. Once you place an order, several things happen.
First, Amazon checks your payment card to make sure the funds are available. Then Amazon has to pack the goods and load them onto lorries. All of this happens in an Amazon distribution centre. There is no synchronous API call for the Amazon backend to pack and ship the products. Once the system has confirmed your payment, the front end gathers information describing the event and places your account number, your payment card details and what you bought into a packaged event and puts it in the cloud and in a queue. Later, another piece of software removes the event from the queue and starts the packing and shipping.
The key point here is that these processes can all run at different rates.
Improving team collaboration
Event-driven architectures encourage the independence of the development team because of the loose coupling between publishers and subscribers.
Decoupled applications also allow you to build new features faster.
Adding new features or extending existing ones can be simpler with event-driven architectures, because you add new events or modify the ones that already exist. This process removes complexity from your application.
Conclusion
When building a solution on the cloud, the choice between an API-driven architecture and an Event-driven architecture is clearly strategic. Even if the first seems simpler because it is more widely adopted by teams, the second will optimise your development time and your costs in the medium and long term. You should therefore analyse your business objectives so as not to choose a default model that could affect your expansion.
If you would like advice on this subject, contact the Premaccess team!
Contact us