Hacker News Reader

Comment by breckinloggins | Hacker News Reader

Interesting.

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.

View on HN

Rather than providing information to the user by which they can access an alternate, asynchronous request/response flow, why not separate the server from the web-ui from the server for the backend processing system, and when there is too much load on the backend system to effectively do synchronous request/response, failover to an asynchronous workflow?

I thought I remembered reading somewhere that techniques like this only move the back-pressure to other parts of the system rather than solve the problem. There's a load point beyond which you have almost no choice but to throw requests away.

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...

Probably this one?

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.

Yes, that one. Thank you.

> I thought I remembered reading somewhere that techniques like this only move the back-pressure to other parts of the system rather than solve the problem.

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.

Reply on news.ycombinator.com