Configuration options for synchronous consistency

You can configure how Reltio applies consistency in Lightspeed based queries at the tenant level, object level, or request level. Lightspeed predicate queries are optimized for high-cardinality, single-attribute lookups (such as unique identifiers) and are not designed for compound multi-attribute search patterns.

The sections below describe each option and outline when it should be applied.

1 - Tenant-level configuration

Configure the Reltio Lightspeed™ Data Delivery Network (Reltio Lightspeed) to enable strong or eventual consistency using tenant-level and object-level settings. Add this to your tenant configuration to apply strong consistency to all entities by default:

"predicateAPIConfig": {
  "enabled": true,
  "consistency": "strong"
}
      

2 - Object level configuration

Use this configuration to enable or override consistency behavior for specific object types within a tenant.

Strong consistency mode can be enabled at the object type, attribute, or crosswalk (source type) level. When configured at any of these levels, the respective objects are indexed synchronously. All other objects follow the tenant-level default (eventual) consistency.

For example, you might want to enforce read-after-write guarantees for Individual entities involved in real-time activation flows, while allowing other entity types like Organization or Location to use asynchronous processing.

To override consistency at the object level, add the indexingConfig object to the relevant section of your tenant configuration for the scope you are configuring (object type, attribute, or crosswalk/source type).

"indexingConfig": {
  "predicateEnabled": true,
  "consistency": "strong"
}
  

If this setting is omitted, the entity type inherits the value from the tenant-level predicateAPIConfig.

The system indexes an object synchronously when strong consistency is enabled for the respective object type, attribute, or crosswalk (source type). If none are configured, it follows the tenant-level or request-level setting.

3 - Request-level configuration

Use the following query parameter to override default behavior at runtime:

POST /entities?options=strongDDNConsistency
  

This parameter enforces strong consistency for a single API call, even if your tenant or entity type is configured for eventual consistency.

Here’s a full example of a request using this override:

POST https://<reltio>/reltio/api/<tenantID>/entities?options=strongDDNConsistency

[
  {
    "type": "configuration/entityTypes/Individual",
    "attributes": {
      "UUID": [
        { "value": "1" }
      ],
      "Full_Name": [
        { "value": "Emma Thompson" }
      ],
      "Phone": [
        {
          "value": {
            "Type": [{ "value": "Working" }],
            "Phone_Number": [{ "value": "(555) 123-4567" }]
          }
        }
      ]
    },
    "crosswalks": [
      {
        "type": "configuration/sources/PP",
        "value": "1101"
      }
    ]
  }
]
  

Behavioral precedence

For an overview of when and why to use this setting, see Understanding synchronous updates in Reltio Lightspeed.

Operational characteristics of synchronous consistency

Enabling synchronous consistency eliminates search lag but increases write latency for Lightspeed API write operations (POST, PUT, PATCH to /entities). When enabled, Lightspeed API write operations wait for the search index to update across the Lightspeed index before returning a response, ensuring that changes are immediately visible in search and query results. As a result, write operations take longer to complete than in the default (eventual) consistency configuration. There is no SLA (Service Level Agreement) for write operations in either consistency mode. Write latency increases with the number, size, and cardinality of indexed attributes, particularly for multi-valued attributes and high-cardinality data models.

Enable synchronous consistency only when immediate search visibility is required for your business process and higher write latency is acceptable.

The GetById GET /entities/{id} operation is always strongly consistent across both eventual and synchronous configurations because it retrieves data directly from the primary data store, not from the Lightspeed search index. As a result, it always returns the latest saved version of the entity.

Use synchronous consistency when immediate search visibility is required and higher write latency is acceptable. Otherwise, use eventual consistency when short search delays are acceptable and write performance is a priority.