APIs vs Events in Microservices | Which one is better?

The great debate about whether to use APIs vs Events will never stop. Some software developers and architects swear by the simplicity of an HTTP REST API or some RPC framework like gRPC. Other think that's a rudimental approach and that messaging (aka events) are the only way to implement a system with high cohesion and low coupling.
I have coded and design several systems with both integration approaches. I am going to share my macro-architectural rules that I am applying today in my modern designs.
After watching this video, you won't have to guess anymore. You will know exactly when to use one approach or the other.
A lot of the information I shared is based on these books:
(These are affiliate links. If you click on the link and make a purchase, I will receive a commission)
Domain Driven Design amzn.to/3r0ZHeT
Enterprise Integration Patterns amzn.to/3suVDUw
Cloud Native Patterns amzn.to/45Vb332
Software Architecture Patterns for Serverless Systems amzn.to/3qWeM1o
🤝 Do you want to connect with me? / Do you need my services? 🤝
Visit my website: marcolenzo.eu
Add me on LinkedIn: / marcolenzo
Add me on Twitter: / marco_lenzo
📝 Subscribe to my newsletter! 📝
news.marcolenz...
#api #softwarearchitecture #eventdrivenarchitecture

[@MarcoLenzo]

Who's the winner? APIs or Events? Let me know what you use in your systems 🤓

[@pavelernestonavarroguerrer7871]

Excelent video, and you are right about the most important part: Materialized view was the only right answer that I got for a common client-service integrartion problem!

[@MarcoLenzo]

Thank you for sharing your feedback. I have to admit it is a solution not everyone appreciates, but in my own experience it is key to keep microservices decoupled and efficient in a system where events drive most of the integration.

[@LukeDavoli]

Marco, your videos are absolutely fantastic. You make this and many other topics so simple and easy to understand. I am so grateful you're doing what you're doing, thank you!

[@MarcoLenzo]

Thank you very much Luke! Comments like this are fuel to make more videos 🙏

[@READBOOKIQBAL]

Great stuff, really insightful. Keep this up !

[@MarcoLenzo]

Thank you 🙏

[@bralabala]

great way to learn something new

[@MarcoLenzo]

Thank you!

[@LawZist]

love your vids! waiting for more advanced conncepts

[@MarcoLenzo]

Sure! If you'd like to see some topic in particular let me know 🙂

[@opleno-dev]

Could materialized views create unnecessary risks in terms of consistency? E.g. the publisher changes something and the consumer stops receiving updates, misleading the client. Btw gracias for this pleasant afternoon watching your videos

[@MarcoLenzo]

Yes, absolutely! There might be scenarios where strong consistency is more desirable than eventual consistency. As always, it depends a lot on what are your system requirements and the business it is meant to support.
The main issue with strong consistency is that it is difficult to achieve if you intend to distribute your logic across different microservices. If you decide not to allow materialized views and store the information only at the source of truth, you will be forcing all other microservices that need that piece of information to have a hard dependency on the source of truth. Now you have another type of risk. You might be unable to perform operations in multiple services if the source of truth is offline, is experiencing issues, or there's a network partition. You might be tempted to introduce caching, but isn't a cache subject to become stale like a materialized view?
I think the key is "defining well what are the responsibilities of your microservices". Within a microservice is way easier to maintain strong consistency, as it is in a monolithic application. If you identify well your subdomains, you will make sure that all functions and data are grouped in a cohesive way that will make it very easy to keep consistent where it matters.
If you take the example of orders and logistics in an online shop, getting updates about the status of the package, it is not something that requires strict consistency with the order status. As long as we have no data loss on the message broker, we are guaranteed that at some point (eventually) those two subdomains will become consistent. You need to be able to spot these nuances in your business requirements to figure out what works best for you.