Live data from Hacker News

Why disaster happens at the edges: An introduction to queue theory

thenewstack.io

61–62 of 62 posts

Re: Why disaster happens at the edges: An introduction to queue theory

#61
post #53

Earlier quoted context omitted.

> The battle in an organisation is convincing people to look at flows at all. In my experience people love metrics that track stock (we have X widgets or can handle Y orders) and not flows (we built A widgets and sold B widgets). This reminds me of an entrepreneurship class I took in college where the professor emphasized the importance of cash flow, something I hadn't considered much and found somewhat counterintuit…

Queue theory is a lot of fun. There aren't a lot of variables needed to characterise a queue (rate in, rate out, variance of both the rates encoded into a probability distribution). But there are a lot of observable variables (queue length, wait times, utilisation of the servers, probability of there being a queue when a new customer enters the system, probability of the queue overflowing, etc). That means the system…

I'll check out that resource and re-read your post a few times. Thank you very much for replying.

Re: Why disaster happens at the edges: An introduction to queue theory

#62
post #44

Earlier quoted context omitted.

Assuming you have queues and stuff that can hold the requests in the intermediary time. Some systems will just start dropping the data or crashing and loose data. If you have a queue or something in the middle then the failure is potentially recoverable or never happens in the first place.

Queues don't fix overload: https://ferd.ca/queues-don-t-fix-overload.html

I don’t think anyone was suggesting that they did. (Seems like a bit of a strawman to me)

However they do allow you to smooth or average spikes that could otherwise be problematic.

In your articles analogy I am able to drain a pot of pasta down the sink even though I might not be able to pour the same pot down the drain.

Post reply on HN