GitHub
Getting startedInstall, connect and make your first request.ConfigurationServer, memory, persistence and environment settings.Clients & SDKsConnect with Go, Node.js, Python or the Redis CLI.Data structuresStrings, hashes, lists, sets, streams and more.Architecture256 shards, RESP networking and the storage engine.PersistenceSnapshots, append-only files and recovery.Security & ACLAuthentication, TLS and scoped command access.Clustering & replicationGossip, hash slots, replicas and Sentinel.MonitoringPrometheus, slow logs and health checks.HTTP APIIntegrate using JSON over HTTP.Command referenceSearch command syntax across the upstream modules.BenchmarksStorage and TCP results, hardware and methodology.FeaturesEverything inside the CacheStorm binary.ChangelogReleases and development changes.Brand assetsDownload the CacheStorm SVG logo and mark.
↑ ↓ to navigate · Enter to openCacheStorm docs
DocumentationThe engine

Architecture

256 shards, RESP networking and the storage engine.

Source snapshot: baf028b·View upstream source ↗

One server, a focused core

CacheStorm is written in Go. A standalone process brings together protocol handling, command routing, sharded in-memory storage and optional persistence. The Go module uses native Go dependencies, including a Lua interpreter and YAML configuration library. No CGO toolchain is required by the documented build.

Request lifecycle

  1. A Redis-compatible client connects to the RESP listener, normally on port 6380.
  2. The protocol layer parses an incoming command and its arguments.
  3. Authentication and command routing determine whether the request can execute.
  4. The handler operates on the relevant in-memory data structure.
  5. Persistence records mutations when enabled; the protocol layer serializes the response.

256 memory shards

The storage engine distributes keys across 256 shards. Sharding reduces the amount of shared work contending on one global store and supports concurrent access from client goroutines.

This design is why the benchmark page distinguishes sequential and parallel storage measurements. A direct store call measures different work from a complete TCP request.

Familiar wire protocol

The server implements RESP command handling for Redis-compatible clients. You can use redis-cli and Redis libraries to begin testing. CacheStorm extensions, such as tags and namespaces, sit alongside familiar commands.

Compatibility should be evaluated against your application's actual operations. See clients and SDKs and the command reference.

Storage lifecycle

  • Expiry: TTLs let cached data expire automatically.
  • Eviction: configurable policies respond to a configured memory limit.
  • Persistence: AOF and snapshots support recovery when enabled.
  • Replication and clustering: provide multi-node deployment options.

HTTP and observability

An optional HTTP listener exposes management and integration endpoints. The metrics plugin provides a Prometheus endpoint; slow logs help investigate expensive requests. See HTTP API and monitoring.

Read the implementation