3 ms·
circuit breakers /can/ make sense, if done rationally. kinda like that line in fallbacks vs failovers where "if the second system is so reliable why bother with
by pluto_modadic 3y ago
circuit breakers /can/ make sense, if done rationally. kinda like that line in fallbacks vs failovers where "if the second system is so reliable why bother with the first?"
https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/ https://aws.amazon.com/builders-library/avoiding-fallback-in...
(fallback: e.g., using direct DB instead of cache, failover: second cache/API)
- hinkley 3y ago> if the second system is so reliable why bother with the first. Hmm. That's a difficult one to unpack. Sometimes services need to be reliable in different dimensions. And that first service just might not be able to scale high enough to do some more esoteric operation on the data. Though I could see someone arguing that from the user's perspective the first and second system are trying to pretend to be the same thing. I think the services I have the hardest time shooting are the ones that exist to prevent priority inversion. I maintain a batch processing system I have a hard time justifying in some ways. I get more value out of it as a guineapig for new tools and techniques we may want to apply more broadly, than I get from the actual task it performs, but I certainly don't want the core system trying to handle it either. It'd be a lot more noise. So I want to kill it, and I want to keep it. Some tasks have escalating priority over time, and trying to mix them with tasks that don't can be problematic.