Caching
bloom_cache provides a unified, backend-agnostic server caching layer modeled on djangors-cache for expensive computations, database results, and entire HTTP responses.
Swappable Cache Backends
All backends implement the unified BloomCache interface (get<T>, set<T>, delete, clear, getOrSet<T>) with JSON serialization:
InMemoryCache
Bounded in-memory cache with true O(1) Least-Recently-Used (LRU) eviction and TTL checks.
DatabaseCache
SQL-backed cache storing entries in bloom_cache_entries via PostgreSQL or SQLite.
RedisCache
Distributed caching using package:redis driver with millisecond TTL precision.
Cache Stampede Prevention (getOrSet)
getOrSet<T> deduplicates concurrent in-flight computations for the same key. When multiple concurrent requests miss the cache simultaneously, the computation function runs exactly once, and all callers receive the resolved result.
HTTP Response Caching Middleware
BloomCacheMiddleware caches complete GET responses. It automatically enforces safety rules:
- Method Safety: Only
GETrequests are cached. - Cookie Protection: Responses containing
Set-Cookieare never cached to prevent session leakage. - Dynamic Opt-Out: Handlers can bypass caching via
x-bloom-no-cache: trueorcache-control: no-store.