Fault tolerance

When working with the Fraudio API, you'll interact using standard HTTP messages. While most responses will provide a 200 OK status code, it's important to account for potential issues like network outages or problems with newly released features. We strive to minimize these occurrences, but it's crucial to prepare for them as well.

Setting Request Timeouts

The appropriate request timeout depends on your specific use case. We suggest the following default settings:

• For low-latency endpoints like the fraud score endpoint, we recommend a 2-second timeout. Our actual response times are much faster, in accordance with our Service Level Agreement (SLA). Timeouts exceeding 2 seconds are rare, generally due to intermittent network issues or cold starts. If necessary, you may decrease this timeout to match the 99th percentile latency outlined in the SLA.
• For endpoints where latency is less critical, such as the chargebacks endpoint or merchant account information endpoint, we advise a 15-second timeout. This accounts for worst-case scenarios, such as cold starts.

Implementing Retry and Backoff Strategies

Retry strategies should be employed for timeouts and network errors. We recommend two types of retries:

Immediate retries

• Immediate retries are suitable for time-sensitive requests, such as scoring a transaction during live payment processing. In most cases, an immediate retry will produce the same result as the initial request. If the processing pipeline permits, we suggest one retry attempt. Backoff periods are not practical in this context due to the time-sensitive nature of the request.

Backfills

• Backfills are used when a response isn't received within the required timeframe. A backfill is considered necessary when data arrives significantly later than expected, such as during an outage. Backfills inform Fraudio of missed events, ensuring our fraud models have complete and consistent data. If possible, we recommend using a queuing mechanism to store unfulfilled requests. Backfill attempts can employ exponential backoff, with a maximum delay of 3 days.

Warning

Please note that implementing backfills is more complex than retries, as they can involve lengthy delays. As a result, many clients opt for a manual backfill process, providing data dumps as needed.

Managing request volume

Our API and services are designed to handle peak loads and scale up automatically when capacity is reached. Under normal operation, implementing flood controls is unnecessary.

However, in the event of an outage, you may experience a buildup of requests on the client side. When our services resume, we recommend sending 10 concurrent requests until the backlog is cleared. This should allow for a catch-up rate of 100-200 transactions per second, based on average latency.

For large data dumps (e.g., historical data or manual backfills), we offer separate processing methods. Please consult your Fraudio representative for more information.