excache
A cache layer in Elixir, built on the OTP actor model. Concurrent, resilient to single-process failures, with real tests.
A cache layer in Elixir on the OTP actor model. Concurrency without races, resilience to single-process failures, and real tests. The trick is making sure one element toppling does not drag down the rest.
Overview
A cache shared across many threads is one of the classic hard concurrency problems. excache shows that Elixir and the OTP actor model turn that problem into something you can handle without locks and without a quiet fear of deadlock. Instead of fighting shared memory, you move state to where nobody reaches into it in parallel.
It is a project about two properties at once: concurrency without races and resilience to failure. Both flow from the same OTP philosophy, where state lives in a process and errors are not swept away but isolated.
The actor model turns the concurrency problem inside out
In most languages a cache shared across threads means locks, mutexes and a quiet fear of deadlock. Elixir goes another way: every piece of state lives inside a process that handles one message at a time. Instead of locking shared memory, you send a message and get a reply.
The race over the data structure simply does not exist, because nobody reaches into it in parallel. The same guarantee you have to fight for with mutexes in other languages is here a free property of the model.
Let it crash instead of defending
In OTP you do not wrap every operation in a defensive block against failure. Instead you let the process crash and a supervision tree brings it back in a clean state. It is the opposite of defensive programming: you do not hide the error, you let it topple one process and trust supervision to rebuild it.
excache leans on this directly: one cache process dying does not topple the whole layer, because the other processes live independently. The corrupt state vanishes with the process, and its successor starts clean instead of dragging broken data along.
The test for this property is to deliberately kill a process mid-traffic and check the layer still answers. If the whole cache goes down with one process, the supervision tree is put together wrong, and a good test catches that at once.
This is a counterfactual test in its purest form: you do not check that the system works when everything goes well, you check that it survives the failure it is meant to survive. A test that never sees a process die proves no resilience at all.
Resilience as a property, not a patch
The result is a layer that treats failure as a normal operating state, not an exception to patch. Concurrency is safe by design, because nobody shares memory, and a single failure is local, because supervision rebuilds only what fell.
The layer's properties and where they come from
| Property | Where it comes from |
|---|---|
| No races | one process, one message at a time |
| No locks | communication via messages |
| Failure isolation | state enclosed in a process |
| Return to a clean state | the supervision tree |
More projects
More work from the same category - see how we tackle similar challenges.
Have a similar project?
Get in touch - a quote is free and comes back within an hour.