Question - best way to implement in a serverless environment with concurrent executions

[lext05]

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?

[github-actions]

This issue is stale because it has been open 30 days with no activity.

[lehoanggiap]

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]

This issue is stale because it has been open 30 days with no activity.

[hiSandog]

For serverless concurrency, persisting full breaker.stats snapshots 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]

This issue is stale because it has been open 30 days with no activity.