NimbusKV Recipes & Quickstart
Verified production patterns for caching, atomic counters, worker coordination, reactive session stores, and FastAPI integration.
5-Minute Quickstart
From installation to production concurrency in 7 progressive steps.
Install the core NimbusKV library from PyPI. Zero compulsory external dependencies.
Instantiate your reactive, lock-free store. Thread-safe across all CPU cores.
from nimbuskv import NimbusKV
# Create an in-memory store instance
store = NimbusKV()Readers never lock or block writers; reads achieve millions of ops/sec.
store.set("app:mode", "production")
store.set("user:42", {"name": "Priya", "role": "admin"})
print("Mode:", store.get("app:mode"))
print("Has user?", store.exists("user:42"))Generational priority queue guarantees accurate cleanup without memory leaks.
# Key automatically evicts after 10 seconds
store.set("session:token_xyz", {"uid": 42}, ttl=10)
# Background priority queue manages cleanup without memory leaksSingle deterministic mutex prevents lost updates and CAS retry storms.
store.set("counter:hits", 0)
# Read-modify-write executed safely under the write mutex
new_count = store.atomic("counter:hits", lambda c: (c or 0) + 1)
print("Updated count:", new_count)Copy-on-write event notifications dispatched without holding write locks.
def on_state_change(key, action, old_val, new_val):
print(f"Key '{key}' was {action}: {old_val} -> {new_val}")
store.subscribe("system:status", on_state_change)
store.set("system:status", "online")Condition-variable coordination without wasteful polling loops.
# Wait up to 5 seconds until key meets the condition
is_ready = store.wait_for("job:101", lambda val: val == "COMPLETED", timeout=5.0)
if is_ready:
print("Worker finished task successfully!")Practical Production Recipes
Production-ready code patterns verified against NimbusKV v3.1.
1. Caching Repeated Computations (Function Memoization)
PerformanceProblem: Expensive database queries or CPU-heavy calculations executed repeatedly with the same arguments.
Reads are completely lock-free. If two threads simultaneously compute for an uncached key, the last set() wins cleanly without corrupting memory.
2. High-Concurrency Atomic Counter
ConcurrencyProblem: Concurrent threads incrementing request counts, metrics, or rate limit buckets losing updates due to race conditions.
In v3.1.0+, atomic() uses a deterministic short mutex instead of CAS retries. Every call runs its mutation exactly once without wasting CPU.
3. Worker Pool Task Coordination with wait_for()
CoordinationProblem: Worker threads waiting for an asynchronous background job to finish without burning CPU in a sleep/poll loop.
Uses threading.Condition internally. Zero CPU cycles wasted while waiting; awakens immediately upon publication.
4. Reactive Web Session Store with Auto-Expiry
Web & APIProblem: Managing authenticated session tokens that must expire automatically when idle.
Overwriting a key with a new TTL updates the generational priority queue without leaking stale timer references.
5. Durable SQLite Persistence
PersistenceProblem: Requiring fast in-memory performance while surviving process restarts with durable on-disk backup.
Reads hit in-memory HAMT at full speed. Writes commit to the SQLite WAL backend under the write lock.
6. FastAPI Lifespan State Integration
Web & APIProblem: Sharing a single, thread-safe NimbusKV store instance across all asynchronous route handlers in FastAPI.
NimbusKV is completely thread-safe and non-blocking for reads, making it ideal for FastAPI worker threads.