Bummer the link is broken. I read via UnfitFootprint's link.
This feels both like a good write-up, but an argument for why you often need to reach for multiple solutions when creating distributed system. Sure a fallback can have issues, but in the example given (website -> cache -> db) I can't help but feel that a circuit breaker pattern should also have been in play to catch other types of failures.
Distributed systems are dynamic systems and rarely will one type of solution or pattern cover the entire space of possible failures.
By the logic of the article, a circuit breaker for the DB query would act as a fallback for the fallback. A path that would be executed in production even less frequently, and which would be more difficult to test for its effectiveness. Surely, you can test whether the circuit breaker is triggered, but would it reduce DB load enough to keep the fulfillment system running?
Link broken for anyone else…? Article: https://builder.aws.com/content/3EuS9Sakq7L3VLQIF3qzfMfke1Y/...
Yes. Thanks.
Bummer the link is broken. I read via UnfitFootprint's link.
This feels both like a good write-up, but an argument for why you often need to reach for multiple solutions when creating distributed system. Sure a fallback can have issues, but in the example given (website -> cache -> db) I can't help but feel that a circuit breaker pattern should also have been in play to catch other types of failures.
Distributed systems are dynamic systems and rarely will one type of solution or pattern cover the entire space of possible failures.
By the logic of the article, a circuit breaker for the DB query would act as a fallback for the fallback. A path that would be executed in production even less frequently, and which would be more difficult to test for its effectiveness. Surely, you can test whether the circuit breaker is triggered, but would it reduce DB load enough to keep the fulfillment system running?
[flagged]