Is it a good idea to use QueueBackgroundWorkItem for event hub send data operations?

Question

I have a wep api that getting more than 100 request in a second and it needs to answer back fast.

There are two main job in every request:

• Get the answer from cache and return it to user
• Send the result to event hub (for some hourly calculations)

The second part doesnt interest the api caller. So any errors and slowness, timeouts shouldnt change my response time.

My questions:

1. So how should be the implementation?

2. Can i use "HostingEnvironment.QueueBackgroundWorkItem" for that kind of background job? What are your suggestions?

3. Can using async version of event hub send methods change anything about scalability and performance for the possible implementations?

Answer 1

You could put the results in a queue and have a background process read that queue at its own pace. This allows you to group results together and send them to the eventhub using a batch. See https://azure.microsoft.com/en-us/documentation/articles/event-hubs-programming-guide/#batch-event-send-operations.

Putting items in some sort of queue should be quite fast and fail safe as long as the process reading it is separated. As a bonus when the web app fails/stops whatever the events are not lost but stored in the queue. You could use Azure Storage Queue (https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-queues/) in combination with a simple webjob or an Azure Function (https://azure.microsoft.com/en-us/documentation/articles/functions-bindings-storage/) to process the events.

See this somewhat older article http://blog.stephencleary.com/2014/06/fire-and-forget-on-asp-net.html for more background info on why this setup instead of using the QueueBackgroundWorkItem option and this answer for even more reading material: Web Api - Fire and Forget.