Overview

Ubiq is designed to enforce data protection policies directly in the runtime path without making every application request dependent on a live backend call.

To support that model, Ubiq SDKs cache the runtime context needed to perform protect and unprotect operations locally within the application process. This allows applications to maintain low latency, reduce backend dependency, and continue operating through transient network or service disruptions when the required context is already cached.

Although this capability is commonly referred to as key caching, Ubiq caching is broader than key material alone. Depending on the SDK, configuration, and integration mode, the runtime cache may include:

• Key material required to perform protect and unprotect operations
• Dataset policy and configuration information
• Authorization context, such as API key access or identity-to-dataset access

In practice, this means Ubiq can make identity-aware data protection decisions efficiently at runtime without forcing a round trip to Ubiq services for every encryption, decryption, tokenization, masking, or unmasking operation.

Why This Matters

Many data protection systems work well at rest, but become difficult to apply directly in high-volume application, API, database, gateway, analytics, or data pipeline workflows. If every policy, authorization, or key decision requires a remote lookup, data protection can introduce latency, availability dependencies, and operational complexity.

Ubiq’s caching model is designed to avoid that tradeoff.

By caching the runtime context required for protection operations, Ubiq allows applications to enforce centrally managed data protection policies close to where data is used. This helps customers apply encryption, tokenization, masking, and access-aware unprotection in the runtime path without turning Ubiq into a per-transaction dependency.

This helps customers achieve three outcomes:

• Low-latency enforcement: protect and unprotect operations can run without a backend call on every transaction.
• Resilient operations: applications can continue operating when required runtime context is already cached, even during temporary network or backend disruptions.
• Centralized control: keys, dataset policies, and authorization context remain centrally managed while enforcement happens efficiently in the application runtime.

Runtime Enforcement Without Runtime Bottlenecks

Ubiq is commonly deployed in performance-sensitive environments, including applications, APIs, databases, data pipelines, gateways, and analytics workflows.

In these environments, data protection cannot require a remote policy or key lookup for every individual operation. That model would add unnecessary latency and create avoidable runtime dependencies.

Ubiq’s caching model allows the SDK to enforce centrally managed data protection policies locally within the application process using cached key material, dataset policy/configuration, and authorization context.

The result is a runtime enforcement model that is both centrally governed and operationally efficient: policy, key management, and authorization remain centralized, while protect and unprotect operations can execute locally within the SDK when the required context is available in cache.

What Is Cached

Ubiq does not only cache cryptographic material. The SDK can cache the runtime enforcement context needed to make protect and unprotect operations fast, resilient, and policy-aware.

This context can include three categories of information.

1. Key Material

The SDK may cache key material used during protect and unprotect operations.

For structured data protection, this generally means the keys associated with a configured dataset. Once retrieved, the SDK can reuse those keys for subsequent operations against that dataset until the cache entry expires or is otherwise invalidated.

For unstructured encryption, key behavior is different. See Structured vs. Unstructured Caching below.

2. Dataset Policy and Configuration

The SDK may cache dataset-level configuration and policy information.

This tells the SDK how to process a given dataset, including details such as:

• Which dataset is being used
• Which protection method applies
• Which algorithm or format-preserving behavior applies
• Which configuration rules apply to the operation
• How the related key material should be applied

This is important because the SDK does not only need keys. It also needs to know how those keys should be used for a specific dataset.

3. Authorization Context

The SDK may cache authorization context so it does not need to re-authorize every operation against Ubiq services.

The exact authorization context depends on the integration mode.

API Key Mode

When using API keys, the SDK can cache the validity of the API key and its access to specific datasets.

For example:

• API key A is valid
• API key A has access to dataset customer_email
• API key A has access to dataset customer_ssn

Once cached, the SDK can perform subsequent authorized operations for that API key and dataset combination without contacting Ubiq for every request.

Identity-Integrated Mode

When using identity-integrated access, the same concept applies at a user or identity level.

For example:

• User identity [email protected] is valid
• That user has access to dataset customer_email
• That user does not have access to dataset customer_ssn

Once cached, the SDK can apply user-level authorization decisions locally for subsequent requests, within the configured cache expiration window.

This avoids calling Ubiq services or the customer identity provider for every protect or unprotect event.

Cache Lifecycle

Caching generally follows one of two patterns.

Opportunistic Cache Population

By default, cache entries are typically populated as they are first needed.

For example:

1. The application performs a protect or unprotect operation.
2. The SDK determines that it does not yet have the required runtime context.
3. The SDK retrieves the required keys, dataset policy/configuration, and authorization context.
4. The SDK performs the operation.
5. The SDK stores the runtime context in cache for future operations.

Subsequent operations against the same dataset and authorization context can use the cached material until it expires.

Explicit Cache Loading or Warm-Up

Some SDKs also support explicit cache loading or warm-up patterns.

This allows an application to load cache entries before customer-facing transaction traffic begins.

Common examples include:

• Loading cache entries during application startup
• Preloading datasets that are known to be used frequently
• Refreshing cache entries in the background
• Moving cache retrieval outside of latency-sensitive request paths

This approach is useful for high-throughput applications where the first request should not pay the cost of retrieving runtime context from Ubiq services.

Cache Expiration

Cache entries are governed by expiration settings.

The default cache expiration is commonly set to 30 minutes. This default is intended to balance performance, resiliency, and security freshness.

Shorter cache durations provide faster propagation of authorization, key, or policy changes, but may increase backend calls.

Longer cache durations reduce backend calls and improve resiliency during network disruptions, but can increase the amount of time before authorization or policy changes are reflected in a running application.

Customers should choose cache expiration based on their requirements for:

• Runtime performance
• Availability and resiliency
• Authorization freshness
• Policy-change freshness
• Security and compliance expectations

Security and Freshness Tradeoff

Caching improves performance and resiliency, but it also introduces an intentional freshness window.

For example, if an API key, user identity, access group, or dataset policy is changed, an application with cached authorization context may continue using the previously cached context until the cache expires.

This is expected behavior and should be accounted for when selecting cache TTLs.

For environments that require faster enforcement of authorization or policy changes, configure a shorter cache expiration.

For environments that prioritize runtime resiliency and low latency, configure a longer cache expiration.

Structured vs. Unstructured Caching

Structured and unstructured encryption use different caching models.

Structured Data

Structured datasets are configured and named in Ubiq.

For example:

• CUSTOMER_EMAIL
• CUSTOMER_SSN
• ACCOUNT_NUMBER

Because these datasets are known and configured, the SDK can retrieve and cache the related dataset configuration, policy information, authorization context, and key material.

This also enables explicit cache loading patterns in supported SDKs, where a known set of structured datasets can be loaded into cache ahead of time.

Structured caching is well-suited for:

• Database fields
• JSON fields with known sensitive attributes
• Application fields
• API payload fields
• Data warehouse columns
• Repeatable protect and unprotect operations against known datasets

Unstructured Data

Unstructured encryption behaves differently.

For unstructured encryption, each encryption operation may generate a new data encryption key. That data encryption key is wrapped and stored as an encrypted data key within the ciphertext header.

Because the encrypted data key is stored with the ciphertext, Ubiq does not maintain a server-side list of every encrypted data key created for a given unstructured API key.

As a result, unstructured encryption does not support the same style of cache preloading by dataset name that structured encryption supports.

This is most relevant when the same encrypted objects are read repeatedly.

Recommended Implementation Patterns

Caching behavior and configuration can vary by SDK or integration. Use the guidance below as a general implementation model, and review the caching documentation for the specific Ubiq SDK or integration you are using for exact configuration options, method names, preload behavior, and object reuse patterns.

Ubiq maintains library-specific documentation in the relevant GitHub and GitLab repositories. These docs may include cache configuration fields, default settings, TTL configuration, structured versus unstructured cache behavior, supported preload or warm-up methods, and language-specific examples or constraints.

Reuse SDK Objects

Applications should reuse SDK credential, encryption, and decryption objects where supported.

Creating new SDK objects for every operation can reduce or eliminate the benefit of caching because each new object may start with an empty cache.

Recommended pattern:

• Initialize SDK credentials or client objects once
• Reuse them across operations
• Allow the SDK cache to remain available for subsequent protect and unprotect calls

Avoid this pattern:

• Create credentials
• Encrypt or decrypt one value
• Destroy credentials
• Repeat for every request

That approach can cause unnecessary backend calls and higher transaction latency.

Preload Frequently Used Structured Datasets

For latency-sensitive applications, preload frequently used structured datasets at startup when supported by the SDK.

This helps ensure the first customer request does not need to retrieve runtime context from Ubiq services.

Good candidates for preloading include:

• High-volume fields
• Fields used on most requests
• Fields required during application startup or login flows
• Fields used in latency-sensitive APIs

Use Reasonable Cache TTLs

A 30-minute cache expiration is a common default and works well for many applications.

Customers may adjust this value based on their needs.

Use a shorter TTL when:

• Authorization changes must take effect quickly
• Dataset policy changes must propagate quickly
• The environment has strict freshness requirements

Use a longer TTL when:

• Low latency is critical
• Network resiliency is critical
• Applications must continue operating through temporary connectivity issues
• Dataset policies and access patterns change infrequently

Separate Cache Warm-Up From Customer Transactions

Where possible, cache warm-up should happen outside of customer-facing request paths.

Examples include:

• Application startup
• Background refresh jobs
• Scheduled warm-up tasks
• Health-check or readiness workflows

This prevents the first customer request from paying the cost of fetching runtime context.

Example Decision Guide

Operational Behavior During Network Issues

If the SDK has the required runtime context in cache, it can continue performing authorized protect and unprotect operations without contacting Ubiq services for each request.

This improves resiliency during:

• Temporary network issues
• Routing problems
• Cloud-provider disruptions
• Short-lived backend availability issues
• Latency spikes

Once the cache expires, the SDK may need to contact Ubiq services again to refresh runtime context.

If Ubiq services or the network are unavailable at that time, operations that require refreshed runtime context may fail until connectivity is restored or the context is available again.

Key Rotation and Cached Keys

Key rotation and key caching are related, but separate concepts.

Ubiq supports key rotation while preserving the ability to access previously protected data.

Depending on the type of key rotation performed, the resulting ciphertext behavior may differ.

Data Key Rotation

When a data encryption key is rotated, new protect operations may produce different ciphertext for the same plaintext value.

Previously protected data remains accessible because Ubiq maintains the relationships needed to resolve the correct key material for unprotect operations.

Primary or Master Key Rotation

When a primary or master key is rotated, the underlying data encryption keys may remain the same but become associated with the new primary key material.

In this case, existing ciphertext may not change because the data encryption key used to protect the value has not changed.

Applications should continue to be able to unprotect existing data after rotation, assuming they remain authorized and have valid runtime context.

API Key or Identity Revocation

If an API key or identity is disabled, future operations should fail once the SDK no longer has valid authorization context.

If authorization context is cached, the revocation may not be reflected in that running process until the relevant cache entry expires or the cache is cleared.

For high-security use cases where revocation must take effect quickly, use shorter cache TTLs and consider operational procedures to restart services or clear cache when needed.

What the Cache Does Not Do

The SDK runtime cache is not a customer data store.

The cache is used to retain runtime context needed for protection operations, such as keys, dataset policy/configuration, and authorization context.

The cache should not be treated as:

• A system of record
• A customer data repository
• A replacement for application data storage
• A replacement for identity governance or access-review processes
• A replacement for SIEM, audit, or monitoring workflows

Monitoring and Audit

Customers should monitor Ubiq activity through available event and audit integrations.

Relevant events may include:

• Protect and unprotect activity
• Administrative activity
• Dataset configuration changes
• Key rotation events
• Identity or API key changes
• Access group changes
• Anomalous usage patterns

For enterprise environments, forwarding Ubiq events to a SIEM or observability platform can help correlate Ubiq activity with broader application, identity, and security events.

Summary

Ubiq caching is more than simple key caching.

The SDK can cache the runtime context required to perform protect and unprotect operations efficiently, including:

• Key material
• Dataset policy and configuration
• Authorization context

This improves performance by reducing backend calls and improves resiliency by allowing applications to continue operating when the required runtime context is already cached.

The right cache configuration depends on the customer’s balance of latency, resiliency, authorization freshness, and security requirements.