🧘‍♂️️Lightweight fault tolerance primitives for your resilient and modern Python microservices

Hyx (/ˈhʌɪx/) is a set of well-known stability patterns that are commonly needed when you build microservice-based applications. Hyx is meant to be Hystrix (Java), resilience4j (Java) or Polly (C#) but for the Python world.

Key Features

• Implements five commonly used resiliency patterns with various configurations based on advice and experience of industry leaders (e.g. AWS, Google, Netflix)
• Idiomatic Pythonic implementation based on decorators and context managers
• AsyncIO Native Implementation
• Lightweight. Readable Codebase. High Test Coverage

Requirements

• Python 3.9+
• AsyncIO-powered applications (no sync support?)

Installation

Hyx can be installed from PyPi:

``` sh pip install hyx

or via poetry

poetry add hyx ```

Component Map

| Component | Problem | Solution | Implemented? | |-------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------| | 🔁 Retry | The failures happen sometimes, but they self-recover after a short time | Automatically retry operation on temporary failures | ✅ | | 💾 Cache | | | | | ⚡️ Circuit Breaker | When downstream microservices have got overloaded, sending even more load can make the situation only worse. | Stop doing requests to your failing microservice temporarily if amount of errors exceeded expected thresholds. Then see if the given time helped the microservice to recover | ✅ | | ⏱ Timeout | Sometimes operations may take too much time. We cannot wait that long or after that time the success is unlikely | Bound waiting to a reasonable amount of time | ✅ | | 🚰 Bulkhead | If executed without control, some code can take too much resources and put down the whole application (and upstream services) or cause slowness of other places of the application | Fix the amount of calls to the code, queue other calls and fail calls that goes beyond your capacity | ✅ | | 🏃‍♂️ Rate Limiter | The microservice can be requested with any rate even one that can put it down if happens by accident | Limit the rate your system can be accessed by | ✅ | | 🤝 Fallback | Nothing can guarantee you that your dependencies will work. What would you do when it's failing? | Degrade gracefully by defining some default values or placeholders if your dependencies are down | ✅ |

Inspired by Polly's Resiliency Policies

Acknowledgements

• resilience4j/resilience4j
• Netflix/Hystrix
• slok/goresilience
• App-vNext/Polly
• Diplomatiq/resily