A bit of advice about the code presented in that tutorial: It's a good approach when you running on only a single server. When your application needs to scale out to running on multiple machines, you'll need to re-think the use of that static ConcurrentDictionary<>. Recall that static variables are only in the memory of the app pool. Since you'll have app pools running on your code on multiple machines, how will you get this shared state to go across machines? The old approach was to use AppFabric, but MS has abandoned that.
I just realized, even on the single server, there is an issue with that throttling approach given there. If the sys admin performs an IISReset, or if somebody manages to crash the app pool, then a brand new instance of the app pool will be started up. New instance means that the past never happened so anybody who had exceeded their limits previously doesn't look like they exceeded their limits.
As for the daily total throttling, the best durable way to do this check is to actually recompute the totals from your database. Trying to keep this in memory is prone to error. Like as I mentioned above, consider the IISReset or application crash. Also consider that IIS's default settings is to spin down an app pool if it's been idle for 20 minutes. So any daily total you may have in memory will be lost when the app pool is shutdown. You'll need no recompute anywhich way. Yes, you could cut down on the database hits by doing some in memory caching, but you'll need to balance this out with the complexity this will add to your code.
