Hi Sergey,

I don't think the circuit breaker pattern is clumsy, and I don't think it manifests workarounds and tech debts in the system. It is an amazing pattern that typically protects us against failures of third-party systems we don't control. What is more, failure is something you are not planning, and you have to always be prepared for it. Using CB is a sign of thinking seriously about resiliency - in that case, on a client's end. Not using CB and assuming that even mastered dependencies will always work - that's clumsy.

Regarding your feelings about the CW-based solution:

I get you. I really do. This is why I stated in the article that this pattern is for specific cases, and the classic approach is the best. Check out the Summary section and the decision tree.

Regarding SLAs: CloudWatch has an SLA of 99.99% (https://aws.amazon.com/cloudwatch/sla/) and AWS Lambda 99.95%, so it's not lower (https://aws.amazon.com/lambda/sla/).

Regarding the suggested solution: This works in the way you described. It collects invocation statuses through CW Metrics, and then we don't need any aggregation logic as we are reacting to the changes based on quantitative metrics, so we have it out of the box.

Regarding cost: I suggested doing that in the article based on CloudWatch Metrics (not logs), which are already there and free (free meaning it is part of lambda billing). So no, it won't be cheaper.