Asynchronous message passing should be the default choice for inter-service communication.
sandor11 Feb 13
This statement is not new and I am not the first to say it, but I completely agree.
There are many aspects of system/service design which lead me to this conclusion. When looking through this lens, we should assume some level of an event driven architecture.
In it's most simple form, synchronous data requests are both a leaky abstraction and a breaking of encapsulation, leading to more tightly coupled, less resilient systems. It's the equivalent in my view, to having getters and setters on your classes. Which should be avoided.
I think it's worth clarifying, this does not apply for external facing systems. REST based APIs are the best way for external systems (including UIs) to interact with your system. This doesn't mean you lose asynchrony internally, and takes some design thought.
In my opinion, event driven systems are better, holistically, for organisations. They allow an improved mapping of both the business and technical domain. Increased levels of resilience, responsiveness and changeability.
Primarily however, they remove the impedance mismatch suffered by technical people talking to business people as the focus shifts from 'what data do we store' to 'what interesting things happen' in our system and everyone can have input when discussing events.
All this leads to the level of correctness of a system, from the business domain point of view, being much better than when we try to have BA's and domain experts descend to the data layer in order to explain how things work.