diff --git a/content/en/docs/tasks/traffic-management/circuit-breaking/index.md b/content/en/docs/tasks/traffic-management/circuit-breaking/index.md
index 60c285a9d363..71f1e4829281 100644
--- a/content/en/docs/tasks/traffic-management/circuit-breaking/index.md
+++ b/content/en/docs/tasks/traffic-management/circuit-breaking/index.md
@@ -13,6 +13,8 @@ and outlier detection.
 Circuit breaking is an important pattern for creating resilient microservice
 applications. Circuit breaking allows you to write applications that limit the impact of failures, latency spikes, and other undesirable effects of network peculiarities.
 
+Note that circuit breakers can misinterpret a partial failure as total system failure and inadvertently bring down the entire system. In particular, sharded systems and cell-based architectures are vulnerable to this issue. For example, let’s say only one of your database shards is overloaded and other shards are working normally. Usually in such circumstances, the circuit breaker either assumes the entire database (i.e. all shards) is overloaded and trips which negatively impacts the normal shards, or the circuit breaker assumes the required threshold hasn’t been exceeded and doesn’t do anything to mitigate overloading of the problematic shard. In either case, the result is not optimal. A workaround is that the server indicates to the client exactly which specific part is overloaded and the client uses a corresponding mini circuit breaker. However, this workaround can be complex and expensive.
+
 In this task, you will configure circuit breaking rules and then test the
 configuration by intentionally "tripping" the circuit breaker.