Thanks for taking time to read and adding a comment. What I have written is based on reading and my own experience. It can be only good to have discussion with others who knows better on the topic.

1) From my end, I've heard people referring to an architectural style when talking about microservices, while others won't make any distinction and see microservices as an architecture. Frankly, I have always considered both these terms to be more or less synonymous, simply because I still do not see a clear difference. What is the use of having that difference, other than just a wording? It's probably time to avoid ambiguous/overloaded usage of terminology on this topic. I would be happy to hear from you.

2) Well this part is a matter of perspective. I agree that from the user perspective, a system that is malfunctioning is equivalent to dead, not trustworthy. That would lead a mess to deal with because it looks is alive, but behind the scene it is a mess (user data incoherence or corruption, business process half-way, so on). Good news here is there are ways to compensate that. The user may feel like the system is functioning, but fact is it's not. That is is just technical debt that we won't deal really with.

3) On the EDA topic. It seems you have some profound knowledge and experience. In my opinion, all software architectures (or styles) have pros and cons, I would consider them carefully when designing a system. What and when to use, but not with hard restriction! What matters is to take the best of the two (several) worlds. I have seen and experience projects EDA and microservices coexist.

I'll be very grateful if you could provide some guidance based on your experience on EDA. How is EDA contradicts microservices definition and philosophy?

I hope you would spare me a bit of you time again. Best regards,