Circuit Breaker Design Pattern
doc.akka.io
doc.akka.io
For event signup, preorder, and ticket purchasing sites (which tend to experience little or no load most of the time and an insane amount of load right before some important deadline or right after an announcement), I wonder if this could be used to redirect the user to a page that either says "take a number and we'll call you back" or a page that says "we're experiencing high traffic, you can send an email at this link and we'll get back to you as soon as we can."
The email link thing might work, but the "take a number" system would probably be under the same traffic constraints that caused the intended transaction to fail. Maybe not, though. Maybe that could work on a cheaper, more scalable mechanism.
It was something like [1] but I don't think that was the exact article I read.
[1] http://mechanical-sympathy.blogspot.com/2012/05/apply-back-p...
I think that redirecting to an alternate asynchronous mechanism via a "send us an email" notification is essentially equivalent to an automated shift to an asynchronous mechanism in terms of shifting load to a different part of the system -- doing either is appropriate only if you've got a process for handling asynchronous requests that won't fall-over (or produce results unacceptably out of user expectations) under load despite the fact that processing requests synchronously would.
Lots of times, however, this is the case, so long as you don't have a long-term load problem, but only a spiking load problem.
> There's a load point beyond which you have almost no choice but to throw requests away.
Yes, but that point differs depending on how you are processing requests -- and (for a system with direct human interactions) how you are setting client UX expectations.
http://ferd.ca/queues-don-t-fix-overload.html
Queues and similar things help flatten out the spikes, but they don't add capacity. Like many of these tools, use with discretion.
It's an really interesting read, and kind of a proto-devops book.