Service Continuity and Caching

Overview

Ubiq-protected workflows may need to continue operating during temporary connectivity interruptions, network latency, or short-lived service disruptions. These workflows may include applications, databases, API gateways, data pipelines, file processes, or other systems where Ubiq is used to protect and unprotect sensitive data.

Ubiq libraries and integrations support secure local caching to reduce dependency on live service connectivity for every protect or unprotect operation.

This document explains:

How Ubiq caching supports runtime continuity
What Ubiq can cache
Expected behavior during temporary connectivity interruptions
Cache limitations
Cache duration and configuration
Cache lifetime and object lifecycle considerations
Recommended production practices

Ubiq does not store or host the customer’s underlying data. Protected data remains in the customer’s systems, databases, applications, files, or data stores.

Summary

Scenario	Ubiq Capability
Temporary internet interruption	Secure local caching allows continued operation when valid cached material is available
Ubiq service temporarily unreachable	Protect and unprotect operations can continue using valid cached material
Network latency	Caching reduces the need for live service calls on every operation
New dataset, identity, or operation with no prior cache	Connectivity to Ubiq is required before the operation can complete
Dataset definition or permission changes during an interruption	Changes are applied after the workflow can reconnect and refresh its cache
Cache expiration during an interruption	Operations requiring expired cached material require connectivity to Ubiq before continuing
Short-lived object or instance lifecycle	Cache may be too short-lived to provide meaningful continuity or performance benefit

Runtime Continuity with Caching

Ubiq libraries and integrations support secure local caching to reduce dependency on live service connectivity for every operation.

When caching is enabled and valid cached material is available, Ubiq-enabled workflows can continue protect and unprotect operations during temporary connectivity interruptions. This helps support production workloads where temporary internet, routing, or service connectivity issues should not immediately interrupt workflow behavior.

Caching is intended to reduce the need for a live Ubiq service call for every protect or unprotect operation. When the required material is already cached and still valid, the workflow can continue using that local cache during temporary connectivity interruptions. This is especially useful for production workflows where short-lived network issues should not immediately prevent access to previously authorized data operations.

Caching is the recommended configuration for production deployments.

What Ubiq Can Cache

Depending on the library, integration, and implementation, Ubiq can cache operational materials such as:

Key material
Dataset definition and configuration
Identity context and metadata
Encrypt/decrypt permissions associated with the authorized identity and dataset

The dataset definition includes the configuration used by the Ubiq library or integration to process protected data for a given dataset. Encrypt/decrypt permissions are retrieved with the dataset definition and key material for the authorized identity and dataset.

Cached materials are used to support Ubiq protection and access decisions. The cache is not a copy of the customer’s underlying protected dataset, database, file store, or application data.

Most Ubiq libraries and integrations include more than one cache. Cache behavior is local to the library, integration, workflow, and running instance. A cache in one library, integration, or running instance does not automatically carry over to another.

Typical cache criteria include the credentials, identity, and dataset used by the workflow. For example, if a workflow uses two different identities that reference the same dataset, those may be represented as separate cached entries.

Server-Side Restrictions and Cacheable Material

Some access restrictions are evaluated before Ubiq returns cacheable material to the requesting workflow.

For example, if a workflow uses permitted IP address restrictions, those restrictions are validated by Ubiq before the requested dataset definition or key material is returned. If the request does not satisfy the configured restrictions, Ubiq does not return the requested material.

If the request is permitted and the required material is returned, that material may then be cached according to the applicable cache configuration. During a temporary connectivity interruption, behavior depends on the validity and lifetime of the local cache.

Behavior During Temporary Connectivity Interruptions

When Ubiq is temporarily unreachable and valid cached material is available, the workflow can continue using the cached material until the configured cache period expires.

This can help mitigate temporary issues such as:

Internet connectivity interruption
Temporary inability to reach Ubiq services
Network latency or routing issues
Short-lived service disruption

If valid cached material is not available, the workflow must be able to reach Ubiq before completing operations that require that material.

Cache Limitations

Caching supports continuity for materials that are already known, authorized, and valid within the configured cache duration.

Caching does not create new cached entries while Ubiq is unreachable, and it does not receive updates made during the interruption window until connectivity is restored.

The main limitations are:

New activity with no prior cache

If the workflow has not previously used Ubiq for a given dataset, identity, or operation, there may be no cached material available. The workflow will need connectivity to Ubiq to retrieve the required material before completing the operation.

Examples include:

A new dataset that has not been cached
A new identity that has not been authorized or cached
A first-time protect or unprotect operation with no existing cache

Updates made during the interruption window

If dataset definitions, dataset configuration, identity context, or encrypt/decrypt permissions are updated while the workflow cannot reach Ubiq, those updates cannot be pulled into the local cache until connectivity is restored.

During the interruption window, the workflow may continue using the currently cached material until it expires.

Cache expiration

If the configured cache period expires while Ubiq is still unreachable, operations requiring that cached material will require connectivity to Ubiq before continuing.

Cache Duration and Configuration

Cache duration is configurable through Ubiq configuration settings. In many libraries and integrations, the default cache duration is 1800 seconds, though customers should confirm the applicable default for the library, integration, and version they are using.

The appropriate cache duration should be selected based on the customer’s security requirements, availability requirements, and expected network conditions.

Longer cache periods can improve continuity during temporary connectivity interruptions. Shorter cache periods can reduce the amount of time a workflow uses cached material before refreshing from Ubiq.

Customers should choose cache duration based on the risk and availability profile of each production workflow.

Cache Lifetime and Object Lifecycle

Cache effectiveness depends on both the configured cache duration and the lifecycle of the Ubiq library, integration, client object, or runtime instance used by the workflow.

In many implementations, cached material is associated with the Ubiq object, integration process, or runtime instance. If a workflow creates a new Ubiq object for every protect or unprotect operation, the cache may be short-lived and may not provide meaningful continuity or performance benefit. Similarly, in a web application, if a new Ubiq object is created for every request, cached material may not live beyond that individual request.

In other words, cache configuration alone is not enough. The application, workflow, or integration should also be implemented in a way that allows cached material to remain available across the operations that need it.

For production deployments, workflows should generally use long-lived Ubiq objects, library instances, integration processes, or client instances where appropriate, so cached material can be reused across operations or requests during the configured cache period.

The exact object lifecycle pattern may vary by library, integration, workflow architecture, and runtime environment.

Recommended Production Practices

For production deployments, Ubiq recommends:

Enable caching for workflows that require continuity during temporary connectivity interruptions.
Select cache duration based on the workflow’s security and availability requirements.
Use long-lived Ubiq objects, library instances, integration processes, or client instances where appropriate so cached material can be reused across operations or requests.
Confirm expected behavior for new datasets, new identities, dataset definition changes, permission changes, first-time operations, and expired cache.
Test workflow behavior during simulated temporary connectivity interruption.
Document cache configuration and object lifecycle expectations as part of the production deployment plan.

Key Takeaways

Ubiq supports runtime continuity through secure local caching.

Caching helps workflows continue operating during temporary connectivity interruptions when valid cached material is available.

Caching supports previously known, authorized, and valid materials. It does not create new cached entries while Ubiq is unreachable, and it does not receive updates made during the interruption window until connectivity is restored.

Cache effectiveness depends on both cache configuration and implementation pattern. Workflows should generally use long-lived Ubiq objects, library instances, integration processes, or client instances where appropriate so cached material can persist across operations or requests.