Caching

Overview

Caching is the practice of storing a reusable copy of data or a computed response so later requests can be served with lower latency and reduced origin load. Caching is not suitable for every payment operation; mutable status, authorization decisions, balances, and sensitive responses require explicit freshness and privacy rules.

The principal risks include stale balances or statuses, cross-tenant data leakage, cache poisoning, incorrect variation, stampedes after expiry, hidden dependency on cached data, and inconsistent invalidation. Testing Caching should cover malformed input, denied access, rate limits, timeouts, duplicates, asynchronous completion, and version changes. Changes to Caching should be checked against older clients, stored payloads, enum growth, default behavior, and retry assumptions.

A production implementation should define cache keys, freshness, invalidation, tenancy boundaries, sensitive-data policy, consistency expectations, and fallback behavior when the cache is unavailable. Where retries, asynchronous delivery, caching, provider failover, or user interaction are possible, the design should make repeated processing safe and preserve enough evidence to query, replay, reconcile, or reconstruct the outcome.

Useful measures include hit ratio, miss latency, stale-read rate, eviction rate, cache-error rate, origin amplification, and incidents caused by incorrect cache keys. Caching is closely connected to Cache-Control Header, Receipt Query, and Integration Monitoring. The Caching contract should define identifiers, validation, authorization, status semantics, errors, limits, and version behavior at the same boundary.

Data handled by Caching should use documented types, units, timestamp rules, nullable fields, and enum behavior to prevent silent interpretation errors.

For Caching, the application should preserve a correlation path from request construction through response, asynchronous completion, and final business state.