And will adding the async keyword to my .NET api make it asynchronous?
No not in the sense of asynchronous architecture. let me explain.
A Restaurant Analogy
Let’s take a real-life example of a restaurant.
And at this restaurant customers need to go to the counter to get served.
In the first example, the server has NOT been instructed to be async by their manager.
So when a customer goes to the counter, they need to wait for a server to be available, and if they wait for too long, they will leave.
When a customer is next, they give their order to the server.
The server will serve the customer and only serve that customer until that transaction is completed.
The manager sees that a lot of waiting customers get annoyed with waiting and leave.
Having viewed this and understood that the restaurant needs to increase the amount of orders the servers can accept, the manager tells the server that while serving one customer, they should try to serve other customers while they wait for another customer’s order to be fulfilled.
The manager has now given the server the async keyword.
Now the server can use the time they would have spent waiting to complete the customer’s order to serve others now.
Now that the server has now been instructed to be async, the server can now use the empty time to perform other activities. Doing so allows the restaurant to serve more customers in less time. This is because the customers waiting time to get to be served is decreased.
However, the underlying type of communication between the customer and the server has not changed with or without the async instruction. Thus the same problems still exist. For example, if the server needs to leave the counter, no orders will be taken, and customers may see the restaurant has no servers and leave.
Also, if it takes a long time for the customer to give their order, the customer may become unhappy and leave.
And the customer is tightly coupled to the server; the customer cannot do other activities apart from waiting at the counter.
The async instruction to the server now makes the server more effective in using their time, thus having positive impacts. But doesn’t change the underlying communication between the customer and the server.
This above approach is a synchronous request (point to point)
Now let’s say the manager sees that he can increase the number of customers he can serve, and it involves removing the need for a customer having to go to the counter to give the order to the server directly.
So the manager hires order takers as well and sets up an order station and a pick-up station for the customer.
The customer still needs to go to the counter to order, but they go to the pick-up point to wait for their order once after they order.
The restaurant can now take customers more orders in the same amount of time.
But the customer still needs to perform the work to get their order. They need to keep looking at their order status to know when to get their order.
This is an asynchronous request API that uses polling.
The manager sees that even though the counter can now take orders quicker, customers still need to wait to collect their orders. They cannot go back to their tables and do other activities until they have their order.
The manager sees that this is causing customer dissatisfaction, so he now has employees take the orders once ready to the customer table. This allows the customer to return to their table and enjoy their time once they give their order.
This is now asynchronous request APIs using webhooks
Customers are happier, but the manager still thinks improvements can be made because, at the moment, the customer still needs to get up and talk to an order taker (or wait for the order taker to go to their table). This is still a problem because the ability to get orders is limited by how quick the order takers are and if they are available.
The manager sets up an order taking solution where customers can now order via an app. And the bar receives the orders via an order system.
The customer can order items without direct communication with an order taker. They can order anytime with their app, no waiting on the availability of an order taker, thus leading to a high degree of decoupling.
And the restaurant no longer needs order takers and can now focus on fulfilling orders.
The manager is happy he can now take more orders and fully focus on making the orders. Still, the manager knows that to keep customers happy, he needs to ensure that the restaurant’s ability to fulfil orders does keep up with the order throughput and does not lag. And even if the bar’s order screen goes down and the bar doesn’t receive orders, the customers can still make orders. And when the screen is rebooted, or the problem is resolved (hopefully quickly), the bar will not have lost orders and can continue fulfilling the orders made.
The bar is now using an event-driven approach with a broker (or platform), which enables in-direct loosely coupled communication using a broker (or a platform)