The client of a system should not be burdened with handling its failures. It should be reliable, responsive, elastic and fault tolerant. Resilient is the smart HTTP client for the new era of reactive systems architectures.
Organisations working in disparate domains are independently discovering patterns for building software that look the same. These systems are more robust, more resilient, more flexible and better positioned to meet modern demands.
The system stays responsive in the face of failure. This applies not only to highly-available, mission critical systems — any system that is not resilient will be unresponsive after a failure
Acording to the reactive manifesto, resilience is achieved by replication, containment, isolation and delegation. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole.
Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a service is not burdened with handling its failures
Resilient takes the HTTP request control flow live-cycle in a transversal way to guarantee end-to-end communication is performed successfully and consistently between different HTTP nodes. It will fallback and retry the request in case of failure, handling errors and status properly and doing failover to the next best available server if required.
Resilient has built-in support for dynamic servers discovering, self refreshing and optional caching. You could provide a list of servers which gives to the Resilient client a list of available URLs of your servers.
Resilient aims to delegate the balancing logic responsabilities in a proper and consistent way on the client-side, providing an extra layer of reliability from the consumer side. It also has build-in support for round robin scheduler in order to provide better load distribution across a pool of servers
Resilient clients store multiple parameters such as network latency, network errors and server errors in order to determinate which is the potentially best available server on every request based on emphirical information of previous communications. This can increase in some scenarios the efficiency of the HTTP client when communicating with multiple backends.
The following algorithm diagram represents (from a high-level point of view) the complete HTTP request livecycle flow and logic encapsulated inside a Resilient client
For more information, see the draft specification for both client and server interfaces