Introduction

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

What about resilience?

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

About

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.

Server discovering

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.

Client-side based balancing

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

Effective emphirical communication

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.

How does it work?

The request flow algorithm

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