Live data from Hacker News

Defcon: Preventing overload with graceful feature degradation (2023)

micahlerner.com

101–107 of 107 posts

Re: Defcon: Preventing overload with graceful feature degradation (2023)

#101

Joining Google a few years ago, one thing I was impressed with is the amount of effort that goes into graceful degradation. For user facing services it gets quite granular, and is deeply integrated into the stack – from application layer to networking. Previously I worked on a big web app at a growing startup, and it's probably the sort of thing I'd start adding in small ways from the early days. Being able to turn o…

it's really great to have such capabilities, but adding them has a cost where only few can afford. Cost in terms of investing in building those, which impacts your feature build velocity and the maintenance

So at my previous place we had a monolith with roughly 700 different URL handlers. Most of the problem with things like this was understanding what they all did.

Applying rate limiting, selective dropping of traffic, even just monitoring things by how much they affect the user experience, all require knowing what each one is doing. Figuring that out for one takes very little time. Figuring it out for 700 made it a project we'd never do.

The way I'd start with this is just by tagging things as I go. I'd build a lightweight way to attach a small amount of metadata to URL handlers/RPC handlers/GraphQL resolvers/whatever, and I'd decide a few facts to start with about each one – is it customer facing, is it authenticated, is it read or write, is it critical or nice to have, a few things like that. Then I'd do nothing else. That's probably a few hours of work, and would add almost no overhead

Now when it comes to needing something like this, you've got a base of understanding of the system to start from. You can incrementally use these, you can incrementally enforce that they are correct through other analysis, but the point is that I think it's low effort as a starting point with a potentially very high payoff.

Re: Defcon: Preventing overload with graceful feature degradation (2023)

#102
post #71
post #2

Am I reading the second figure right? Facebook can do 130*10^6 queries/second == ‭130,000,000‬ queries/second?!

Whats with people lately writing 10^6 instead of 1 million. Its not that big that we need exponents to get involved.

Erosion of education makes basic scientific knowledge very trendy

Re: Defcon: Preventing overload with graceful feature degradation (2023)

#103

Earlier quoted context omitted.

Do you have an ad blocker stopping the requests and causing retries?

I do have ublock origin on everything of mine, so conceivably it's reacting to that somehow. I'm no longer at my computer to be able to look more closely at what it's doing.

Whenever you're running this kind of eyeball test with DevTools, make sure the "Disable Cache" option is _not_ checked. And even then, make sure the requests you're counting were not served from your browser cache. It's possible that only the first page load sends hundreds of requests, and subsequent loads may still initiate those requests, but have their responses served from your browser cache (or your cache is disabled).

I would check myself, but I haven't logged into Facebook in many years. :)

Re: Defcon: Preventing overload with graceful feature degradation (2023)

#104
post #97

Earlier quoted context omitted.

Exactly. I think it’s misguided to blame Meta or Google here. People respond to incentives, and the masses want to buy stuff using e-commerce, hence it’s profitable. I’m oversimplifying, but that’s the root of it. If people instead of buying things from ads were looking for the best ways to purchase offsets for CO2 emissions, then the best minds would be working on that problem.

Right, that's not going to happen though for pretty obvious reasons. Governmental incentives and carbon taxes can make more jobs in CO2, but expecting individual citizens to solve a collective action problem is doomed. At the same time, I think it is fair to ask people to look at what they're doing for/to the world and decide if that's something that fits their values. 300k salary is nice, but almost certainly not so…

By the same token, you are asking people to introspect and unilaterally sacrifice in a way that, for the same reason, is not going to happen for pretty obvious reasons.

I’m on board with solving this at the governmental level FWIW. I support stronger anti-trust enforcement for example (and not just targeting tech).

Re: Defcon: Preventing overload with graceful feature degradation (2023)

#105

Earlier quoted context omitted.

Right, that's not going to happen though for pretty obvious reasons. Governmental incentives and carbon taxes can make more jobs in CO2, but expecting individual citizens to solve a collective action problem is doomed. At the same time, I think it is fair to ask people to look at what they're doing for/to the world and decide if that's something that fits their values. 300k salary is nice, but almost certainly not so…

By the same token, you are asking people to introspect and unilaterally sacrifice in a way that, for the same reason, is not going to happen for pretty obvious reasons. I’m on board with solving this at the governmental level FWIW. I support stronger anti-trust enforcement for example (and not just targeting tech).

Oh yeah totally. I think its easier to do so for one single rarely made decision than a bunch of small ones every day. From like, a practical perspective if you wanted to make one sacrifice that's the one I'd reccomend.

But yea govt level would solve it much better

Re: Defcon: Preventing overload with graceful feature degradation (2023)

#106
post #71
post #2

Am I reading the second figure right? Facebook can do 130*10^6 queries/second == ‭130,000,000‬ queries/second?!

Whats with people lately writing 10^6 instead of 1 million. Its not that big that we need exponents to get involved.

- The comment is referring to a graph that used 10^6 on the vertical axis, which is a very common way to format graphs with large numbers (not just "lately"). It's also the default for a lot of plotting libraries.

- 10^n is more compact than million/billion/etc, more consistent, easier to translate, and doesn't suffer from regional differences (e.g. "one billion" is a different number in Britain than in the US).

I'm not saying it's clearly better than "million" in this specific case, but it's definitely not clearly worse.

Post reply on HN