@cedricmi:I just watched this video, and I can see where you are coming from. In the past several years I have rarely been on a project that didn't have a SQL Server as one component. However, during this time I have also been leveraging several other types of data for specific tasks. One thing that I do a fair bit of is, leverage something like table storage for the bulk data; but then aggregate the data and store it in SQL Server. This is a good way to lower the cost, but get that data into a relational database for reporting etc.
Mainly what I want to say is don't choose one over the other; choose the data storage system by determining the nature of the data.
@robbidog:Thanks, yes we have a lot of automation at hand these days. It is really important to understand when to use it; and that it isn't going to solve every performance issue you face. It can hide issues for longer.
Async enables a server to handle more concurrent requests by suspending execution of a 'long running call'; or in this case when a message is being added to a queue. Async Vs. non-async doesn't affect my choice in when to use a queue. It might delay it slightly, but in a world where we can spin up more servers to handle concurrency; non-async can be scaled up to handle async throughput volumes (to some degree).
I would introduce a queue when: additional latency is not a concern (determine what your threshold is), and secondly when your data store is potentially not able to handle your peak load (this typically requires load testing, and forcasting).
Lastly, I don't want to discount async and languages like Node.js I think that it is the cats pajamas.[H]