Repository navigation
Question - best way to implement in a serverless environment with concurrent executions #781
Description
Hi,
I understand this library has support for saving and loading states using an external storage. However, I am wondering how to best handle concurrent executions and updating the stats.
For example, if breaker.stats stored in an external storage for success is initially 0, and two executions read the state with both functions passing, I assume the breaker.stats would be updated to 1 in both cases. If we were to write stats in both cases to external storage, they would both write 1, when in reality there were 2 successes.
Should we be handling incrementing these stats ourselves and calculating the other fields like percentiles?
Activity
github-actions commentedon Jul 22, 2023
This issue is stale because it has been open 30 days with no activity.
lehoanggiap commentedon Jun 19, 2025
I think that we should implement the locking for the external storage (which is not good), since the circuit breaker state is not so important like user data, we can accept the race condition in the high traffic environment
github-actions commentedon Jul 20, 2025
This issue is stale because it has been open 30 days with no activity.
hiSandog commentedon Jun 26, 2026
For serverless concurrency, persisting full
breaker.statssnapshots seems inherently racy. A more reliable pattern may be to store append-only deltas or atomic counters for the fields that can be merged, then let each execution derive its local breaker state from a bounded recent window. That would avoid distributed locking while making it clear which values are exact counters and which ones, like rolling percentiles, are best-effort in a highly concurrent environment.github-actions commentedon Jul 28, 2026
This issue is stale because it has been open 30 days with no activity.