Yeah, they kind of are really liked ... by the service maintainers who don't have to do the front end work to tell the bad news. The article seems to gloss ove

Yeah, they kind of are really liked ... by the service maintainers who don't have to do the front end work to tell the bad news. The article seems to gloss over that part, which is understandable, because it's probably targeted at... service coders. So how does this work on the front end? One way or another you're communicating to the user that the company/service isn't up to their expectations, SLA be damned. It also gets into the classic issue of queuing requests and dedicating resources. Imagine this: you have 100 customers, but 10% of them take 5-10x longer to serve than the others. This is pretty common. Like airline checkin or border crossings, some people will take 2 minutes, some 20 minutes. But... if you don't have any way of keeping a service handler dedicated to fast queries, all the slow bombs will saturate your workers. So even though one or tow of five service workers could service 80% of the work load quickly, if you can't identify the fast requests from the slow ones and keep a fast track for the fast ones, you're service descends to a response time of handling the worse cases (assuming they are frequent just... enough). Circuit breaking doesn't really help that.