An Erlang in-memory cache library using segmented ETS tables for efficient eviction and quota policies.
Cache is an Erlang library that implements a segmented in-memory cache using multiple disposable ETS tables. It solves the problem of efficient cache eviction and quota management by applying policies at the segment level, outperforming traditional timestamp indexing techniques. The library provides key/value operations, asynchronous I/O, in-place transformations, and support for distributed Erlang environments.
Erlang developers building high-performance, distributed systems that require efficient in-memory caching with configurable eviction policies and TTL management.
Developers choose Cache for its segmented architecture that optimizes eviction and quota handling, its native Erlang integration with ETS tables, and features like asynchronous operations and sharding support, making it ideal for scalable Erlang applications.
Erlang in-memory cache
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Uses disposable ETS tables to apply eviction and quota policies at segment level, destroying the oldest table when criteria are exceeded, which outperforms traditional timestamp indexing as noted in the Inspiration section.
Provides both synchronous and asynchronous variants of operations (e.g., get and get_), allowing non-blocking cache access to improve throughput in high-performance Erlang systems.
Supports apply, append, and prepend functions to modify cached elements directly, with helper functions for accumulators and lists, reducing extra I/O for updates.
Works natively in Erlang clusters with global or local cache instances, enabling cache synchronization across nodes as described in the distributed environment section.
TTL is applied at segment level, not per entry, leading to approximations (e.g., 6 sec accuracy for 60 sec TTL with 10 segments), which limits use in scenarios requiring exact expiration control.
Sharding via cache_shards is marked experimental, with interfaces subject to change in future releases, making it unreliable for production use without stability guarantees.
Requires tuning multiple parameters like n, ttl, size, and memory, with recommendations to use values multiples of n, adding setup overhead and potential for misconfiguration.