Caching (Beta)
🧠 Caching Strategy
To enhance performance and reduce unnecessary image transformations, ImageAura is building a two-tier caching system that temporarily stores previously transformed images either in memory or on disk.
This system is best-effort and non-persistent, meaning cached images are not guaranteed to be available. Users should always provide the original image source (src) in every request.
🔑 Cache Key Generation
Each transformation request must include a unique id parameter. This id, combined with other request parameters (e.g. expires, params, src), is used to generate a hash which acts as the cache key.
This approach:
Uniquely identifies each image transformation.
Prevents recomputation when the same request is made.
Enables cache lookups using deterministic keys.
💾 Caching Layers
ImageAura will implement the following caching layers:
1. In-Memory Cache (Primary)
Offers the fastest response times for frequently accessed or recent images.
Ideal for high-throughput environments.
Memory size is limited and subject to eviction policies.
2. Disk Cache (Secondary)
Used as a fallback when images are evicted from memory or when persistence across restarts is needed.
Cached images are stored on disk using the generated hash as a filename.
Disk cache is temporary and may be cleared without notice.
⚠️ Disclaimer on Cache Reliability
⚠️ Important: PichaX does not guarantee that transformed images will be cached or retained permanently.
Cache storage is opportunistic and based on system load, memory, and disk availability.
Cached entries may be evicted at any time.
Clients must always provide the original image source (
src) in every request to ensure the transformation can be performed.
🔄 Cache Lookup Lifecycle
Request arrives with transformation parameters and
id.A hash key is computed from the request data.
The system checks the cache (memory first, then disk).
If a cached version exists, it is returned immediately.
If not found, the image is fetched, transformed, cached (if possible), and returned.
🚧 Development Status
This caching strategy is currently under development. Additional features such as TTLs, LRU eviction, and manual cache invalidation will be introduced incrementally. Documentation will be updated as these capabilities evolve.
Last updated