Why Asynchronous?
Or why stick to synchronous communications should we ask? It is true that synchronous communications has come to be regarded as the de facto pattern to exchange information between any two endpoints. Think of TCP, HTTP, FTP … . It does indeed exhibit the following advantages:
- Simpler reasoning and tracing: Everything starts when an outbound request in made from the client, and we can step through the whole process all the way until the request is processed by the server and a response is sent accordingly.
- “Instantaneous” feedback: When a client breaks the contract, or the server deems the current request as invalid, feedback is sent right away to the client. This can take the form of response codes, redirects, or event stack traces.
- Natural: In the sense that we like to think about thing A happens before thing B, or thing C happens as a consequence of thing B.
- Translates directly to models: We’re all used to sequence diagrams on UML, and very few people can tell from the back of their head how asynchronous calls are modeled. Instead, we like to think of them as a succession of synchronous calls.
Source: Microservices: Why Asynchronous Communications? – DZone Microservices