Reltio Lightspeed architecture

The core idea behind Reltio Lightspeed is minimizing interactions between internal services. In the case of the Search or GET Object By Id API operations, the platform interacts with several services, such as ElasticSearch and Primary Storage, and executes many requests to construct the final object content (resolve the winner ID, collect reference and analytics attributes). Even though each request typically has single-digit latency, the cumulative latency can be high due to the number of requests.

Additionally, for each request, there is some probability of short/temporary issues that affect latency, such as network delays. The more requests we have, the higher the probability of issues affecting latency and making the time taken for 99% of requests to complete, worse even with a good average number.

Reltio Lightspeed flow

To reduce the number of internal requests when constructing objects, the platform pre-calculates and stores the final object state in a separate storage (materialized view). This reduces the number of internal requests to just one request, in most cases, which significantly reduces the final latency and makes it much more stable.

There is a cost to low latency and increased stability, here are the caveats:

• The objects can be queried only by one attribute, crosswalk, or URI.

• Only the exact equals condition is supported for searching by attributes.

• Only the winner URI may be used when querying by URI.

• A maximum of 10 objects is returned.

• Eventual consistency; there may be temporary inconsistency because the materialized views and indexes are updated asynchronously .