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 🙏

[@LawZist]

love your vids! waiting for more advanced conncepts

[@MarcoLenzo]

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

[@bralabala]

great way to learn something new

[@MarcoLenzo]

Thank you!

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