Calling Application Guidance for Using the InRule SaaS Decision Platform API

InRule Technology’s SaaS option for automated decisioning is designed to deliver exceptional value through fully automated provisioning, deployment, and operation with high availability and elasticity features out of the box.

As with any cloud-based service, when calling the rule execution service it is critical to build in elements to calling applications that improve resiliency in the case of temporary faults that may occur.

Context of the Issue

Numerous components make up the totality of a single rule execution request. While each implementation may vary slightly, these components will typically include things like DNS servers, load balancers, application servers, database servers, and even other external API requests. Each of these items has the potential to generate an error response at any point in the life of a given request.

Failure Handling Strategies

InRule Technology’s recommended technique for dealing with transient error responses is to implement a finite number of retries in the application calling InRule’s cloud-based rule execution service. In many cases, somewhere between one (1) to three (3) retries is sufficient to provide increased reliability of application requests.

Original requests that receive a server error (5xx) should be retried as they could be temporary in nature. Transient faults like these aren’t uncommon in cloud applications; while the InRule Decision Platform doesn’t have hard API limits, in these situations, to increase the likelihood of success on subsequent requests, an exponential back-off algorithm should be utilized.