Synchronous Request/Response

Many developers are very familiar with the synchronous messaging approach. A client sends a request to a back-end and then waits for a response. This style makes a lot of sense: it’s easy to reason about and it’s been around for a long time. The implementation details might have evolved over time.

One of the challenges with synchronous messaging at scale is that we can tie up resources waiting for a response. If a thread makes a request, quite often it sits and waits for a response, utilizing precious resources and doing nothing while it waits for the response. Many clients can use asynchronous event-based implementations that enable the thread to continue doing work, and then execute a callback when a response is returned. If we need to make synchronous requests to a service, this is the way to do it. The client does, however, expect a timely response from the service. See Appendix A in this book for best practices when implementing and consuming APIs with ASP.NET. Many of the concepts discussed are transferrable to other languages and frameworks.