Waiting the other day my thoughts turned again to coordination problems, since I was thinking about how the store needed one of those take a number, now serving schemes.  I don’t think I’ve seen a scheme like that in a software system, wonder why?  Wouldn’t be too hard, in the abstract, to add one to HTTP.  It would be a slight variation on the temporary redirect.  The server’s redirect would include the number, along with a time to delay before the retry.

Today I was tinkering with a Freebsd installation.  It includes a tool that fetches system updates.  The instructions advise me to invoke that tool in a mode that forces it to do a random delay before it actually fires off.  This is to avoid having the entire installed base of systems hit their upgrade server at the top of the hour.  It’s brittle since it depends on the users to use the right mode.  A scheme like the one above would avoid that risk, and it would could be used to help the server tune the load so it can run flat out when the bursts of users show up.

It is almost possible to do this without changing the existing HTTP spec.  For example you set up a Rube Goldberg device with three servers.  One to hand out numbers, one to queue up users, and finally one that actually provides service.  Say you want to sell concert tickets on a first come first serve basis.  As buyers arrive at your server you redirect them, providing a number, to a second server.  This server has only one purpose in live and that’s to make them wait.  A HTTP server configured to do that for a huge number of users is a bit odd to set up but it’s not particularly difficult.  This waiting server finally redirects them to the actual selling server at the appropriate time.  The nice thing about this approach is that it removes the incentive for buyers to attempt to poll as fast as possible.
Curious, I’ve mentioned take a number systems before (includes more amusing picture).