Memory Overhead:
Cachee vs Redis

Per-Key Overhead

Every cache entry carries structural overhead beyond the key and value bytes themselves. This overhead includes hash table metadata, pointers, TTL tracking, and eviction bookkeeping. The difference between Cachee and Redis comes down to architecture.

Redis uses a redisObject wrapper (16 bytes) around every value, plus SDS (Simple Dynamic Strings) headers for both key and value, plus a separate expires dictionary entry for TTL-tracked keys. Cachee stores entries directly in DashMap shards with inline TTL and eviction metadata, avoiding the double-indirection overhead.

Connection Buffers: The Hidden Cost

Redis is an external process that communicates over TCP. Every client connection allocates kernel-level and application-level buffers.

At 10,000 connections (common in microservices architectures), Redis consumes ~330 MB before storing a single key. Cachee operates in-process — function calls, not network sockets — so connection buffer overhead is literally zero.

Persistence & Replication Overhead

Cachee is an in-process cache, not a database. It does not persist to disk or replicate. This eliminates several categories of Redis memory overhead.

• No AOF rewrite buffer: Redis buffers writes during AOF rewrite, consuming up to 2x memory during the rewrite window.
• No RDB fork overhead: Redis BGSAVE forks the process. Copy-on-write means pages are duplicated as they are modified during the fork. Under heavy write load, the forked process can consume up to 2x the parent's memory.
• No replication backlog: Redis maintains a circular buffer (default 1 MB, often increased to 256 MB+) for partial resync with replicas.
• No serialization buffers: Redis serializes values for network transfer (RESP encoding). Cachee returns direct memory references — zero-copy reads.

Memory Fragmentation

Redis uses jemalloc, which allocates in fixed size classes. A 33-byte string gets a 48-byte allocation. A 49-byte string gets a 64-byte allocation. The wasted space accumulates. Redis's active defragmentation feature can reclaim some of this, but it consumes CPU and can spike latency during defrag runs. Cachee's DashMap architecture uses fewer, shard-level allocations that fragment less.

Capacity Planning

Total memory = (per-key overhead + key bytes + value bytes) × key count × fragmentation ratio. The tables below compare Redis and Cachee at common scales with 256-byte and 1 KB values.

256-Byte Values

1 KB Values

The per-key overhead savings are constant (~26 bytes per key), so the percentage savings decreases as value size increases. With small values (256 bytes), overhead is a larger fraction of total memory, so the 20% per-key savings translates to ~19% total savings. With larger values (1 KB), the overhead is diluted and savings are ~14%. The connection buffer savings (potentially hundreds of MB) are in addition to these numbers.

W-TinyLFU Admission Overhead

Cachee uses W-TinyLFU for admission control — a frequency sketch that determines whether a new item should replace an existing one. The frequency sketch is a Count-Min Sketch that uses approximately 4 bytes per tracked item.

The Count-Min Sketch is a fixed-size data structure allocated at startup based on L1_MAX_KEYS. It does not grow with actual key count. Redis LFU uses 24 bits per key embedded in the object header — comparable per-key cost but without the admission gating benefit.

The Tradeoff: Isolation vs Speed

The honest comparison: Redis runs in a separate process with its own memory space. If Redis crashes or leaks memory, your application is unaffected. Cachee runs in your application's process. Its memory is your application's memory.

• Redis advantage: Memory isolation. A Redis OOM does not crash your app. You can restart Redis independently. Memory limits are enforced by the OS.
• Cachee advantage: Zero network overhead, zero serialization, zero connection buffers, 20% less per-key overhead, <1.05x fragmentation, and 667x lower latency (0.0015ms vs ~1ms).

Cachee mitigates the isolation tradeoff with L1_MAX_KEYS: a hard cap on how many keys the cache will hold. Eviction is automatic via W-TinyLFU. Memory usage is bounded and predictable. You are not giving up control — you are trading process-level isolation for microsecond-level performance in a memory-bounded container.