APIs vs Events in Microservices | Which one is better?

have you ever wondered whether to use apis or events which one is better in this video I will help you understand what are the characteristics and consequences of these two approaches by the end of the video you will be able to choose the one that fits better your scenario let's get started when integrating services or applications with apis Services known as the client performs a direct request to service B the server which processes the request and returns immediately a response this indirection style is known as request response and its synchronous it must happen all at the same time if service base offline the interaction phase and services needs to retry it later that is eye coupling between the two Services most apis are implemented in HTTP following the rest architectural strains they are very easy to develop Monitor and they require non-specialized infrastructure and if you get about performance you can use a remote procedure called framework like grpc at the cost of a bit of additional complexity when we leverage messages for integration service a known as the Upstream sends a message to a broker or bus you can think of the broker as a sort of post office or post box service B the downstream retrieves the message from the broker at its own convenience as you can see this process is asynchronous it means that service area and service speed don't need to be online at the same time to collaborate that is slow coupling between the two services this characteristics opens the door to three interaction styles we can still Implement request response as we did with apis we can also Implement a fire and forgetting Direction where the Upstream produces a message without expecting any response at all finally we can implement the pops up pattern where the Upstream service produces a message that is processed by multiple Downstream services as we can see messaging is more powerful and versatile than apis just imagine that the integration Styles we just described are 3 out of many that you can find in this book we also highlighted that messaging lowers the coupling in the system when done properly and it does it not only at random but also during development you can Define messages at the beginning of a project and use them as Conrads each development team can code and test its own microservice without needing any other microservice to be available or mocked the obvious cost of messaging is the need of specialized infrastructure in addition you have complex designs for architects steeper learning care for developers and the challenging observability at runtime anyway let's summarize what we learned in now with the metrics apis are synchronous and support the request response in Direction style they don't require any special infrastructure there is a good design and implement but delete twice coupling within the system messages are asynchronous and support multi-billion Direction Styles they lead to low coupling in the system but require specialized infrastructure there are also more difficult to implement the monitor so which one is better and the answer is it depends however we can Define some macro architectural rules that can guide us during the design phase I'm going to share my Approach the type base on top of Concepts that I read on several books the time living down in the description what I like to do is look at the picture and make system level decisions if we do that we can see that we have three types of integration we have clients like browsers mobiles or third-party applications integrating with our system I call this the client system integration we have the necessity to integrate our own system with other systems this could be systems written by other development teams in our company or even third-party systems I call this the inter system integration finally we have to integrate macro services within our own system this is intra system integration let's have a look at each one of them decline system integration is possibly the most critical in this scenario we want the integration experience to be as simple as possible we need to Define very clear interfaces that require no specialized Hardware or software apis are the obvious choice here feeling about it all major players in our industry offer a developer portal with API specification to facilitate the integration with their products this is a de facto standard we can also use apis for index system integration for very similar reasons even in this scenario we want to favor ease of integration because we have our system needing to connect with the system that has been developed by someone else possibly other party company additionally these systems tend to be completely segregated from an infrastructure perspective thus messaging would not be feasible in this particular setting finally we have intra system integration so we want to connect the microservices in our system and that's at a fair call we could use apis because they are easy to implement and that require no specialized infrastructure however the issue with the apis is that they lead to tighter coupling in the system and I know that as developers we are fascinated by systems like Amazon and Netflix but there is a reason why will call this a microservice death star this is effectively an under pattern where services are highly interdependent and this leads to assisting that it's possibly slow inflexible and fragile because service failures can Cascade to a large portion of the system messaging on the other end allow us to decouple the macro services in our system the Upstream component can publish a domain event without knowing which Downstream components we subscribe to it additionally in the systems failures do not Cascade aggressively I think messaging is a superior choice in this scenario however there is a problem that we still have to solve this is possibly the most important part of this video so make sure to continue watching that is the scenario where an external client performs a request to our system we've decided to make this communication synchronous over API which means the microservice saving the request must reply immediately however the replying microservice might need data that's managed by another microservice to validate or process the request in this case the logistic service manages the status of the shipments it might seem that an API call to logistic is the only option to know the status of the shipment we can solve this problem by using materialized views anytime the shipment status is updated the logistics service publishes a shipment domain event at the services can consume these events and store the information they need on their own database this is a materialized view this or soft root of shipment data is still the logistics but our order service can store its own view of it now we can answer external client API requests without the need to conduct any other microservice in the process let's sum it all up apis are preferred for the Simplicity and workspace support for this reason we use them for client integration additionally we also use them when we intend to integrate with other party system on the other end we prefer the flexibility of messages or events when we need to integrate microservices within our system this will create a system that is more resilient to failures and where the microservices are eyelid the couple as usual keep in mind that there will always be scenarios where apis are also the best choice for intra system integration for instance your system might be so simple that it does not justify the additional cost that comes with setting up a messaging infrastructure architecture is always about trade-offs use well your judgment based on your context if you enjoyed the video let me know in the comments like subscribe and share with your colleagues so that everyone can learn something new [Music]

Channel: Marco Lenzo

Views: 3,754

Keywords: API, Event, APIs, Events, Messaging, Publish Subscribe, Pub Sub, event driven architecture, software architecture, software design, event driven architecture microservices, publish subscribe pattern, domain-driven design, event sourcing, microservice architecture, event-driven architecture, event driven, event driven programming, messaging queue, pub sub model, event driven architecture patterns, event-driven architecture pattern, event-driven architecture microservices

Id: EkGw0qgZ5yA

Length: 9min 43sec (583 seconds)

Published: Wed Sep 06 2023