Thread

1. kqr · 1791092760 · focus · HN ↗

   This goes beyond dollar charges. For production code to be reliable, everything needs to have a hard limit.

   Queue lengths, request sizes, response wait duration, message payload size, authentication attempts, allocation rates -- there's always some upper number beyond which the system is so messed up you'd rather it crashes.

   > An argument against this is that businesses don’t want their hosted applications to start throwing errors because some budget was exceeded. I expect that most businesses and individuals would prefer errors to a surprise $10,000+ bill.

   Indeed. If you want a surprise $10,000 bill that's still not an argument against a hard cap -- just set it at $9,999,999 instead, or wherever you don't want the surprise bill. There's always a number that indicates something has gone insane. There's always a sensible upper limit to any operation.

   1. LorenPechtel · 1791143176 · focus · HN ↗

      Yup. Things happen. I'm still picking up the pieces because somebody sent a complex job through broken down into a bunch of separate pieces. Maybe 10x as many parts as normal (and each part caused the run of an external process, a third of them failed to start), one report came back something like 100x as big as normal. All local stuff so it didn't cost anything beyond the production stall.

Unofficial Hacker News client; not affiliated with Y Combinator.