nl.vroste.rezilience

Type members

Classlikes

trait Bulkhead

Limits the number of simultaneous in-flight calls to an external resource

Limits the number of simultaneous in-flight calls to an external resource

A bulkhead limits the resources used by some system by limiting the number of concurrent calls to that system. Calls that exceed that number are rejected with a BulkheadError. To ensure good utilisation of the system, however, there is a queue/buffer of waiting calls.

It also prevents queueing up of requests, which consume resources in the calling system, by rejecting calls when the queue is full.

Companion:
object
object Bulkhead
Companion:
class
trait CircuitBreaker[-E]

CircuitBreaker protects external resources against overload under failure

CircuitBreaker protects external resources against overload under failure

Operates in three states:

  • Closed (initial state / normal operation): calls are let through normally. Call failures and successes update the call statistics, eg failure count. When the statistics satisfy some criteria, the circuit breaker is 'tripped' and set to the Open state. Note that after this switch, in-flight calls are not canceled. Their success or failure does not affect the circuit breaker anymore though.

  • Open: all calls fail fast with a CircuitBreakerOpen error. After the reset timeout, the states changes to HalfOpen

  • HalfOpen: the first call is let through. Meanwhile all other calls fail with a CircuitBreakerOpen error. If the first call succeeds, the state changes to Closed again (normal operation). If it fails, the state changes back to Open. The reset timeout is governed by a reset policy, which is typically an exponential backoff.

Two tripping strategies are implemented: 1) Failure counting. When the number of successive failures exceeds a threshold, the circuit breaker is tripped.

Note that the maximum number of failures before tripping the circuit breaker is not absolute under concurrent execution. I.e. if you make 20 calls to a failing system in parallel via a circuit breaker with max 10 failures, the calls will be running concurrently. The circuit breaker will trip after 10 calls, but the remaining 10 that are in-flight will continue to run and fail as well.

TODO what to do if you want this kind of behavior, or should we make it an option?

  1. Failure rate. When the fraction of failed calls in some sample period exceeds a threshold (between 0 and 1), the circuit breaker is tripped. The decision to trip the Circuit Breaker is made after every call (including successful ones!)
Companion:
object
Companion:
class
trait Policy[-E]

Represents a composition of one or more rezilience policies

Represents a composition of one or more rezilience policies

Companion:
object
object Policy
Companion:
class

Limits the number of calls to a resource to a maximum amount in some interval

Limits the number of calls to a resource to a maximum amount in some interval

Uses a token bucket algorithm

Note that only the moment of starting the effect is rate limited: the number of concurrent executions is not bounded. For that you may use a Bulkhead

Calls are queued up in an unbounded queue until capacity becomes available.

Companion:
object
Companion:
class
trait Retry[-E]
Companion:
object
object Retry
Companion:
class
trait SwitchablePolicy[E] extends Policy[E]

A Policy that can be replaced safely at runtime

A Policy that can be replaced safely at runtime

Companion:
object
Companion:
class
trait Timeout

Applies a timeout to effects

Applies a timeout to effects

Just a thin wrapper around ZIO's retry mechanisms for easy composition with other Policys.

Companion:
object
object Timeout
Companion:
class

Keeps track of successful calls and failures and determines when the circuit breaker should trip from Closed to Open state

Keeps track of successful calls and failures and determines when the circuit breaker should trip from Closed to Open state

Custom implementations are supported

Companion:
object
Companion:
class