Scalability & Performance

This section describes how the Eagle Eye AIR platform scales to meet the performance needs of our ever expanding list of clients running on the service.

How we approach

Eagle Eye AIR systematically scales up and down as changes in load are monitored and detected across our various API services. Our services are highly granular in nature with the ability to divert processing resources under the most use, for example, POS-related services during periods of heavy shopper footfall. We are currently supporting average transaction speeds between 100 and 250 milliseconds and at throughputs in excess of 4000 TPS

Application throttling

Application throughput and capacity are defined per client and we apply a fair usage policy for minor breaches. Breaching allotted capacity will return an error (see below), and we'll be in contact to discuss the situation.

It should be noted that it is possible to receive 429 responses from individual APIs should single instances come under undue pressure in isolation.

Throttled Responses

When a limit is breached a 429 http response will be returned from our APIs. A 429 "Too Many Requests" indicates that the service is unable to process the request or a rate-limit has been breached. These 429 responses will be returned with a "Retry-After" header.

Client Handling

For requests that do not require a retry, such as viewing data in an app, the request should not be retried. For request which require processing, the "Retry-After" header should be respected and the request tried again after the returned period of time in seconds. A random amount of time should be added to the retry to stagger requests.

Response Details

If the system is unable to process a request, a 429 response can be generated from multiple layers of the Application stack.

• Application Layer: In this instance, the response will have a status code of 429, and a "Retry-After" header will be returned. A response body wil be return in JSON format as below.

{
    "errorCode": "CE",
    "errorMessage": "This request has been throttled. Please try again later."
}

• Networking Layer: In this instance only a "head" will be returned with the 429 status code and "Retry-After" header.

Performance testing

As part of our commitment to providing a performant and reliable platform, we conduct performance tests of our APIs at least once every month. These tests simulate the traffic profiles we see in our production environments. Any anomalies or issues are flagged to our engineering teams for remediation.

We also allow our clients to conduct performance tests against our sandbox environment (charges apply), allowing you to test your end-to-end transaction flows.

Eventual Consistency

The AIR platform uses a concept of eventual consistency whereby changes to existing data or creation of new data can be delayed in becoming available and consistent in all areas of the platform. This delay is often negligable but it has a few implications on integration patterns.

Reading API Responses

If an object has been newly created, the calling application should use the response to the API call rather than making an immediate request to retrieve the object. Due to the eventual consistency of the platform, this can lead to objects not yet being available.

Campaign Issuance Limits

The issuance limit on a campaign limits the number of accounts that can be created from a single offer. This limit is not a hard limit as it has flexibility on the limits due to Eventual Consistency. Marketers should be aware a few seconds of delay exists between the issuance limit on the campaign being reached and the campaign changing status to SUSPENDED and stopping any further issuances.