Zeke Lares
Redis is one of the most influential pieces of infrastructure ever written — and it executes every command on a single thread. Even with io-threads, the I/O threads only read and write sockets; the keyspace is still mutated by one thread, so most of a modern CPU sits idle. IronCache is my attempt to ask a sharper question: what does a cache look like if you keep the Redis contract but rebuild the engine, from the first commit, to be the most efficient in the world?
The field, and where each one leaves room
I started by reading the whole landscape, version-pinned, and writing down exactly where each cache leaves efficiency on the table:
- Redis (OSS) — single-threaded command core, fork-based BGSAVE that can roughly double resident memory under write load, no transparent value compression, and a 2024 relicense away from open source.
- Valkey — the open BSD-3 fork; its async I/O threading is a real step up, but it's an evolution of the Redis core, so the ceiling is the inherited architecture.
- KeyDB — multi-threads the shared keyspace behind locks; fast, but a mutated keyspace under spinlocks has a contention ceiling, and the project has been effectively dormant.
- DragonflyDB — the state of the art for vertical efficiency: shared-nothing thread-per-core over io_uring, a low-metadata hash table, forkless snapshots. I borrow that shape wholesale — but it's a C++ / Boost.Fibers stack, and on a single core it's roughly at parity with Redis.
- Memcached — multi-threaded with a great slab allocator and scan-resistant LRU, but no Redis contract, no rich types, no persistence.
- Garnet — RESP-compatible and fast, but a .NET stack with a managed runtime and a garbage collector, not a single static binary.
None of them is a single static binary that keeps the Redis contract, scales across every core with a shared-nothing design, is frugal with memory, and grows from one node to many. That intersection is the whole reason IronCache exists.
Compatible beats Efficient — on purpose
IronCache's tenets are ranked: Compatible > Efficient > Simple > Scalable > AI-Driven. "Efficient" is the reason to exist, yet it sits second — and that ordering is the most important line in the project.
We never bend the wire protocol or a command's observable behavior to win a benchmark.
It would be easy to post a gaudy ops-per-second number by quietly relaxing a command's semantics. IronCache refuses. Compatibility is tiered and explicit: a command is either supported with Redis-identical semantics, or it's documented as unsupported. Existing clients and redis-cli work unchanged against the supported surface — no surprises hiding behind a benchmark.
Shared-nothing, thread-per-core
The engine's core idea is that the keyspace is sharded so each shard is owned and mutated by exactly one core. No hot-path locks, no shared mutable state, every core busy. This is where Rust earns its place: ownership makes "one core owns one shard" a compile-time guarantee rather than a convention you hope everyone respects. The borrow checker turns an architectural rule into something the compiler enforces.
Not a single headline number at maximum pipelining. IronCache measures per-core throughput, tail latency (p99 and p999), and memory at a fixed hit ratio — the numbers that actually predict behavior in production.
Frugal with memory, smart about eviction
Throughput is half the story; bytes per item is the other half. IronCache uses compact in-memory encodings and a low-metadata hash table (in the lineage of Dragonfly's Dashtable), with optional transparent compression for large or cold values, aiming to beat Redis and match or beat Dragonfly on memory. Persistence is forkless — a point-in-time snapshot with bounded, constant extra memory, so saving never doubles the resident set.
For eviction, I skipped the legacy approximated LRU entirely in favor of the modern literature — the W-TinyLFU, S3-FIFO, and SIEVE family — which beat LRU on hit ratio and are far friendlier to a lock-light, per-core design. The policy is chosen by measured hit ratio per byte, not by tradition.
AI as method, not as a hot-path gimmick
IronCache is also an experiment in how to build. It uses AI to mine the world's prior art, propose new approaches, and adversarially verify every load-bearing claim before trusting it — the research corpus and a version-pinned claims.yaml are the output of that process. But the discipline cuts the other way too: AI-Driven is the lowest-ranked tenet, and there is no model inference on the hot path. Learned policies (eviction, admission, autotuning) advise the engine off the critical path; they never sit between a client and its reply. The contract, determinism, and tail latency come first.
Where it is now
Like everything I build lately, IronCache is documentation-first: the architecture is vetted in the open before the engine is written, with every numeric prior-art claim pinned and independently verified. The first vertical slice has landed — a workspace and a server that speaks RESP and answers the Tier-0 connection commands — and the storage engine arrives in thin, reviewable slices after it. The goal isn't to dethrone Redis. It's to find out, honestly and in the open, how much efficiency is still on the table when you keep the contract and rethink everything underneath it.