APIs vs Events in Microservices | Which one is better?

[@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.

[@gustavosserra]

In my limited experience, APIs were able to solve most of the problems. Async messages are valuable, but seldom their cost pays off. Again, just in my experience in areas that I've worked. It was easier to start simple and add more complex solutions only if necessary.

[@MarcoLenzo]

That's a fair point. Avoiding over-engineering (or complex solutions) is possibly the most important thing when developing software. It helps us deliver more quickly a system that's also easier to operate and extend in the future. Both functional and non-functional requirements typically determine if asynchronicity is really necessary. However, my gut feeling is that if you are fine with two microservices talking over API synchronously, there's a very high chance that those two components could be merged in a single deployable where code is segregated with proper modularization. Obviously, each case is different and there's no right or wrong: just trade offs. :)