I’m writing a web site that uses multiple web services with throttle restrictions. I.e. Amazon is 1 request per second, another is 5000/day another is x/minute.
When a user does something, I need to trigger one or more requests to the above services and return the results (to the browser) when available.
The solution need to be flexible so I can easily add/remove services.
I thought of a FIFO queing system, but some later requests may actually be eligible for processing before earlier ones.
I’m asking for a design pattern, but any suitable technology suggestions are very welcome, particularly .NET.
Thanks!
Thanks for your comment. Basically I don’t want to reject requests, I want to queue them and display back to user when they have been processed. Kind of like an ordering system.
0:00:01 Amazon request comes in -> next slot available is in 2 seconds (0:00:03)
0:00:02 x request comes in -> next slot available for this service is 5 seconds (0:00:07)
0:00:03 Amazon request comes in -> next slot available is in 2 seconds (0:00:05)
I need a queue system that will pull the 2 amazon requests out first. I guess my question lies in whether to create separate queues for each service and any common technology (i.e. Service Broker) that is well suited to the throttling, if not I’ll end up creating my own throttling/queueing system, which is why I was looking for common design patterns (i.e. producer/consumer or something) since it’s not FIFO due to the above example.
So far, it looks like a FIFO queue for each service, with it’s own throttling, looks like the way to move forward.