Architecture¶
RedisSettings (@configured, prefix redis)
|
RedisFactory (@factory) --@provides(Redis)--> redis.Redis singleton
| |
RedisLifecycle (@cleanup) -- close() -------------+
|
RedisCacheBackend (@component)
structural CacheBackend (pico-caching Protocol) — no import of
pico-caching; the cache interceptor prefers non-in-memory backends
Design decisions¶
- Opt-in by installation: there is no enable flag. Installing the package next to pico-caching switches
@cacheableto Redis; uninstalling reverts to in-memory. The package boundary IS the feature toggle. - Structural contract, zero coupling:
RedisCacheBackendsatisfies pico-caching'sCacheBackendProtocol without importing pico-caching, so either package can evolve or be absent independently. The integration test in this repo pins the contract. - Fail-open: every backend operation catches
RedisErrorand degrades to a miss (reads) or a no-op (writes). A cache outage makes the app slower, never broken. Hard failures are the caller's choice via the raw client. - Pickle, deliberately:
@cacheablestores arbitrary Python results, so values are pickled. This makes the Redis instance trusted infrastructure — documented, same trust model as a celery result backend. - Namespaced keys: everything lives under
redis.cache_prefix(defaultpico:cache:);clear()scans and deletes only that namespace, so cached entries coexist with your other Redis data. - One sync client:
redis.Rediswith pooling covers the 0.1 scope; anredis.asynciovariant is a planned follow-up if demand appears.