Redis
futomaki.redis
In-memory data store used as a cache, message broker and ephemeral database, offering strings, hashes, lists, sets, sorted sets and streams, with optional persistence to disk.
A Docker Compose file for Redis alone, generated from the catalog and checked by the safety inspector. Sign in and use Kitchen Credits to activate it.
Uses the Medusa cart and payment-session path. This test control does not create an order or capture payment.
Redis holds its dataset in memory and answers over a simple protocol, which is what makes sub-millisecond operations ordinary rather than exceptional. Beyond key-value caching it provides sorted sets for leaderboards and priority queues, streams with consumer groups for durable fan-out, pub/sub for fire-and-forget notification, and Lua scripting for atomic multi-step operations. Persistence is optional and comes in two forms, periodic snapshots and an append-only log, chosen according to how much recent data a deployment can afford to lose. A first deployment sets a password, writes and reads a key, and confirms the chosen persistence mode survives a restart.
You know it worked when
- A client authenticates and receives a reply to a ping.
- A key written by one client is read back by another.
- A value pushed to a stream is received by a consumer in a consumer group.
- The server reports the configured maximum memory and eviction policy.
- Data written before a restart is present afterwards under the chosen persistence mode.
Known sharp edges
- No password is set by default and any client reaching the port has full command access, including deletion of the entire keyspace.
- Without a maximum memory limit and eviction policy the process grows until the host kills it.
- Persistence settings decide how much is lost on an unclean shutdown, and the defaults are not chosen for durability.
- A moving 7-line tag can cross the 7.4 relicensing boundary between pulls, changing the terms with nothing visible changing in the deployment.