This is mostly a design question. I have a web application that takes in data from multiple users on multiple tenants. We also have a desktop application that we want to keep up to date with these data changes from the web app.
Currently the desktop application polls every X seconds retreiving the data. This is costly and results in many redudant requests to the server as nothing has changed. We'd like to switch to more of a PUSH design.
We already have in place a way to send small messages to our desktop applications via Azure Service Bus. Our plan is to push a message over service bus each time the data has been changed by the web app.
However, we want to throttle these change notices. So that we only ever push a notice over service bus no less than every Y seconds. Meaning if one set of users is hammering away on the site generating a lot of changes, we only require the desktop application update no more than once per minute.
Here is the basic idea of the work flow:
User => WebApp => Writes Data to SQL =>
User => WebApp => Writes Data to SQL => Throttler => ServiceBus => Desktop App => Requests Data from SQL
User => WebApp => Writes Data to SQL =>
Are there any Cloud Design patterns that exist to solve this "throttling" issue? Are there any specific Azure "bits" that can help. I'd like to avoid having to just store time data in SQL server checking it each time a request comes in, but that's my best guess right now.
I feel like there should be some combination of AzureStorage Queues, Azure Functions and/or Logic Apps that should be able to accomplish this task. I'd like to avoid Notification Hubs if possible, as they seem to be intended for use in mobile applications and I don't think we are at the scale that is cost effective. But I'm willing hear someone out if that is the best approach.