3 ms·

I don't understand why load shedding wasn't considered here. My experience has been that it's so effective at making a system recover properly that everything e

• petesergeant 2y ago
  Would load shedding in this case just mean that the server replies with “nope” at a much earlier and cheaper stage?
  • strken 2y ago
    Yes, though there's no "just" about it in many cases. If you kick the client out at an early enough stage in processing that the shed requests are only 1% as costly, then 3x retries aren't going to be able to cause a significant CPU spike. I would have liked to see how the simulation behaved, though, because I don't have empirical evidence for exactly what the traffic would look like. You can also configure your client to stop retrying if it sees a load shedding error. That won't protect you against traffic that overwhelms the load shedder, but it's pretty effective against an innocently misbehaving client.
• Fripplebubby 2y ago
  It was considered: > Then Mary and Ben discussed whether load shedding on the server would help, but in the end, they decided that a thick client in this case was acceptable. Just guessing, but it seems that they share the client code between many teams and microservices, so possibly it was just easier to embed the logic in the shared client code. But it seems clear that they consider load shedding to be another way to handle this problem.
  • strken 2y ago
    Yeah, sorry, I meant that I was confused by the brief mention where it was removed from consideration. I would have thought that if the team were planning to implement deadline propagation on the server anyway, they'd reach for load shedding first.