Platform 5 of 12·OS Layer 7 (Memory & Data Layer)·Required in all deployment modes

Scope of this page. Reference material for the Redis platform: what it is, what it is normally used for, and how and why Synedrix OS uses it. It is descriptive, not normative — where this page and a canonical spec in docs/os/ disagree, the canonical spec wins. Platform responsibilities are set by Tech Stack §4; the layer placement is set by Layer Taxonomy Table.

What Redis is

Redis describes itself as “an in-memory data store used by millions of developers as a cache, vector database, document database, streaming engine, and message broker. Redis has built-in replication and different levels of on-disk persistence. It supports complex data types (for example, strings, hashes, lists, sets, sorted sets, and JSON), with atomic operations defined on those data types.”

More precisely for the roles Synedrix OS assigns it: “Redis is a data structure server.” Everything Redis offers the OS is a consequence of a small set of primitives.

ConceptOfficial definition
Key / value“Every data object that you store in a Redis database has its own unique key. The key is a string that you pass to Redis commands to retrieve the corresponding object or modify its data. The data object associated with a particular key is known as the value.”
String“Redis strings are the most basic Redis data type, representing a sequence of bytes.” Integer values stored as strings are operated on by atomic increment commands.
Hash“Redis hashes are record types modeled as collections of field-value pairs.”
List“Redis lists are lists of strings sorted by insertion order.”
Set“Redis sets are unordered collections of unique strings … With a Redis set, you can add, remove, and test for existence in O(1) time.”
Sorted set“Redis sorted sets are collections of unique strings that maintain order by each string’s associated score.”
Stream“A Redis stream is a data structure that acts like an append-only log but also implements several operations to overcome some of the limits of a typical append-only log. These include random access in O(1) time and complex consumption strategies, such as consumer groups.”
Key expiration (TTL)“Key expiration lets you set a timeout for a key, also known as a ’time to live’, or ‘TTL’. When the time to live elapses, the key is automatically destroyed.”
Consumer group“Consumer groups are a consumption strategy that allow multiple consumers to process messages from a single stream.”

Four operational properties matter as much as the data types:

  • Atomic operations. Redis defines atomic operations on its data types, and server-side Lua extends that across keys: “Redis guarantees the script’s atomic execution. While executing the script, all server activities are blocked during its entire runtime. These semantics mean that all of the script’s effects either have yet to happen or had already happened.” MULTI/EXEC transactions provide the same guarantee for a fixed command sequence.
  • Expiry is a first-class server behaviour. TTLs “can be set both using seconds or milliseconds precision”, the “expire time resolution is always 1 millisecond”, and “information about expires are replicated and persisted on disk”. Expiry is master-driven: “Replicas don’t expire keys, instead they wait for masters to expire the keys.”
  • Pub/sub and streams are different delivery contracts. In pub/sub, “published messages are categorized into channels, without knowledge of what (if any) subscribers there may be”, and it “exhibits at-most-once message delivery semantics… If the subscriber is unable to handle the message (for example, due to an error or a network disconnect) the message is forever lost.” Streams are the alternative Redis itself points to: “Messages in streams are persisted, and support both at-most-once as well as at-least-once delivery semantics”, the latter via consumer groups and the pending entries list, acknowledged with XACK.
  • Durability is configurable, not automatic. The documented options are RDB — “point-in-time snapshots of your dataset at specified intervals”; AOF — “logs every write operation received by the server… These operations can then be replayed again at server startup”; no persistence at all; or both combined. Redis’s own guidance: “The general indication you should use both persistence methods is if you want a degree of data safety comparable to what PostgreSQL can provide you.”

Scale-out is by replication and clustering. Replication is “leader follower (master-replica)” and “Redis uses asynchronous replication, with asynchronous replica-to-master acknowledges of the amount of data processed” — the WAIT command adds optional synchronous acknowledgement but “does not turn a set of Redis instances into a CP system with strong consistency”. “Redis Cluster provides a way to run a Redis installation where data is automatically sharded across multiple Redis nodes”, with keys assigned to hash slots and multi-key commands restricted to keys hashing to the same slot unless a hashtag is used.

What Redis is normally used for

The general-purpose cases Redis’s own documentation leads with:

  • Caching — the classic use of strings plus TTLs in front of a slower system of record.
  • Message brokering and event processing — pub/sub channels for broadcast, streams for durable, replayable, consumer-group-based processing.
  • Queuing — lists as the simplest producer/consumer structure.
  • Counters, rate limiting and locking — atomic increments and conditional writes, which Redis documents as named patterns rather than leaving to the caller.
  • Session and hot working state — hashes holding short-lived records that must be read and written on the request path.
  • Search, document, vector and time-series workloads — supported by the modules now included in Redis Open Source.

The common thread is that Redis owns state that must be read and written faster than a transactional database can serve, and that can tolerate being reconstructed or discarded. It is not where the record of truth lives.

How Synedrix OS uses it

Redis is the coordination bus of Synedrix OS and sits at Layer 7 (Memory & Data Layer) of the twelve-layer taxonomy, alongside Supabase PG17, QuestDB, Neo4j and Qdrant. It is required in all three deployment modes.

flowchart LR
  n1([Redis]):::term
  subgraph What it owns
    n2[Hot state]:::agent
    n3[Pub/sub broadcast]:::agent
    n4[Idempotency keys]:::agent
    n5[Rate-limit counters]:::agent
    n6[Heartbeats]:::agent
    n7[Deduplication windows]:::agent
  end
  n1 --> n2
  subgraph What it does not own
    n8[Time-series records and temporal aggregations]:::warn
    n9[QuestDB]:::term
    n8 --> n9
    n10[Lineage influence and relationship graphs]:::warn
    n11[Neo4j]:::term
    n10 --> n11
    n12[Semantic retrieval and similarity search]:::warn
    n13[Qdrant]:::term
    n12 --> n13
    n14[The event record itself]:::warn
    n15[Layer 8 per the Event Taxonomy Standard]:::term
    n14 --> n15
  end
  n1 --> n8
  subgraph Why Redis
    n16[The primitives are the requirements]:::term
    n17[Atomicity without a transaction manager]:::term
    n18[Two delivery contracts explicitly labelled]:::term
  end
  n1 --> n16

What it owns

Per Tech Stack §4, Redis owns:

  • Hot state
  • Pub/sub broadcast
  • Idempotency keys
  • Rate-limit counters
  • Heartbeats
  • Deduplication windows

Its declared access pattern is fast read/write at sub-10 ms latency. Every one of those responsibilities maps onto a specific Redis primitive:

OS responsibilityRedis primitive
Idempotency keysSET <key> <token> NX EX <ttl>. NX means “Only set the key if it does not already exist”, and the reply distinguishes the two cases — OK when “The key was set”, a null reply when “The key exists, and NX was specified… The key was not set.” The first caller proceeds; a replay sees the null and short-circuits. This is what the idempotency_strategy field of the Workflow Contract Spec is implemented against.
Agent invocation identityDurable deduplication is enforced by the unique (tenant_id, idempotency_key) on the Postgres agent_invocations start row. A Redis key may accelerate a check but is not the audit record or the authority; correlation_id is a grouping key, not an idempotency key.
Deduplication windowsThe EX / PX argument on the same write, or EXPIRE on an existing key. The window is the TTL; Redis destroys the key when it elapses, so no sweeper job is needed. Keying on the event envelope’s event_id (Event Taxonomy Standard) makes the window per-event; correlation_id and causation_id stay grouping keys and are not dedup keys, since every event in a causal chain shares them.
Rate-limit countersINCR with an expiry, which Redis documents as its “Pattern: rate limiter”: a counter key per subject per time bucket, incremented on each call and expired automatically. Redis’s own documentation flags the race in the naive form — “If for some reason the client performs the INCR command but does not perform the EXPIRE the key will be leaked” — and gives the fix: wrap the pair in MULTI/EXEC or in a Lua script. Use the fixed form.
HeartbeatsA TTL key written by the live component and refreshed on an interval shorter than the TTL. Liveness is then the existence of the key; a missed refresh expires it without anything having to detect the failure. TTL / PTTL read the remaining time.
Pub/sub broadcastPUBLISH / SUBSCRIBE where loss is acceptable — fan-out of a state change to whichever workers happen to be listening. Where loss is not acceptable, use Streams with consumer groups (XADD, XREADGROUP, XACK) for at-least-once delivery and a pending entries list that survives a consumer crash. The choice between the two is a governance decision, not a style preference: pub/sub is explicitly at-most-once, and “the message is forever lost” if the subscriber is not there.
Hot stateStrings and hashes holding short-lived working state on the execution path, with a TTL. Anything that must survive is written to Supabase.

What it does not own

Layer 7 hosts five platforms with non-overlapping responsibilities. Redis is the fastest and the least durable of them, and that boundary is the whole point:

ConcernOwner
Canonical business state, policies, approvals, audit trails, agent definitionsSupabase PG17 (Layer 7)
Time-series records and temporal aggregationsQuestDB (Layer 7)
Lineage, influence and relationship graphsNeo4j (Layer 7)
Semantic retrieval and similarity searchQdrant (Layer 7)
The event record itselfLayer 8, per the Event Taxonomy Standard

Redis carries the signal that an event happened and the guard that stops it being processed twice. It is not the event log. Nothing whose loss would break auditability may live only in Redis, because the persistence options are a deployment choice and replication is asynchronous by default — “acknowledged writes can still be lost during a failover, depending on the exact configuration of the Redis persistence”. A dropped pub/sub message must never be the only record that a governed action occurred.

Distributed locking deserves the same care. Redis documents SET resource-name anystring NX EX max-lock-time as “a simple way to implement a locking system”, but immediately notes that “the following pattern is discouraged in favor of the Redlock algorithm which is only a bit more complex to implement, but offers better guarantees and is fault tolerant”. Idempotency keys are a deduplication mechanism, not a mutual-exclusion mechanism; do not use one for the other.

How it is operated

Two logical roles, one technology. n8n’s queue mode uses Redis as its execution message broker: the main instance generates an execution, the execution ID goes to Redis, and a worker picks it up and posts completion back. Synedrix OS also runs Redis at Layer 7 as the coordination bus. These are two distinct logical roles that happen to share a platform — n8n’s execution queue is orchestration infrastructure with its own key schema and failure semantics, the OS coordination bus is application state governed by the workflow contract. The n8n page flags this from the orchestration side and it holds equally from here: do not collapse the two onto one logical database without a deliberate decision. Redis’s own separation mechanisms are available and cheap — separate instances, separate numbered databases, or at minimum a reserved key prefix — but note that pub/sub does not respect database numbers at all: “Pub/Sub has no relation to the key space… Publishing on db 10, will be heard by a subscriber on db 1.” Channel names must therefore be namespaced explicitly. Separate instances are the only complete isolation.

Persistence posture is a deliberate choice. For the coordination bus the loss of hot state on restart is usually tolerable, but the loss of an in-flight idempotency window is not — it converts a restart into a duplicate side effect. Whichever posture is chosen (RDB, AOF, both, or none), it should be recorded rather than inherited from a container default, and the retry and error semantics of the affected workflows should be consistent with it.

Clustering constrains key design. In a clustered deployment, multi-key operations require the keys to hash to the same slot, which is what hashtags ({...}) exist for. Key schemas for OS-owned concerns should be designed with that constraint in mind up front, because retrofitting hashtags to a live keyspace is a migration.

OS coordination-bus key templates (normative)

These templates apply to the Synedrix OS Layer 7 coordination bus only. They do not apply to n8n’s queue-mode Redis or to a LangGraph checkpointer Redis instance. Canonical owner of the same list for Task Graph recovery semantics: Task Graph Spec § Redis role.

{tenant_id}:os:idempotency:{scope}:{key}
{tenant_id}:os:lock:{resource}
{tenant_id}:os:heartbeat:agent:{agent_id}
{tenant_id}:os:heartbeat:execution:{execution_id}
{tenant_id}:os:dedup:event:{event_id}
{tenant_id}:os:ratelimit:{counter_name}:{window}
{tenant_id}:os:working:{tier}:{scope_id}:{key}
{tenant_id}:os:queue:{queue_name}
Illustrative example, not a production implementation. Review and test before use.

Rules:

  1. tenant_id always leads the key.
  2. Prefer {tenant_id} hashtags when multi-key operations must share a cluster hash slot.
  3. Values are ephemeral; loss MUST NOT make a Goal or Task Graph unrecoverable from Postgres.
  4. Domain-pack key spaces (for example Trading heartbeats without a tenant prefix) are pack-local exceptions and MUST be documented in the pack’s alignment or domain-pack docs until renamed under a tenant-led template.

The working memory tier

Redis backs the working tier in the Memory Fabric Spec — hot state for an in-flight run, TTL-bound, and explicitly never a source of truth.

The spec turns that last phrase into a testable invariant: a run that cannot be reconstructed from the durable tiers after working memory is lost is non-compliant. Redis holding a value is never sufficient grounds for treating it as true.

Note the distinction from the LangGraph checkpointer, which is also run-scoped and also not truth. The checkpointer holds graph state for a thread; Redis holds coordination state for the OS. They are separate stores serving separate consumers and must not be collapsed, in the same way the existing n8n queue-mode Redis and the OS coordination bus are kept logically apart.

Why Redis

  • The primitives are the requirements. Idempotency, deduplication, rate limiting and heartbeats are not features that have to be built on top of Redis — they are SET NX, TTL, INCR plus expiry, and TTL again. The OS gets its coordination guarantees from documented server behaviour rather than from application code.
  • Atomicity without a transaction manager. Atomic operations on data types, plus Lua scripts with guaranteed atomic execution, give the OS single-round-trip correctness for the check-and-act patterns that govern side effects. That is exactly the class of operation where a race becomes a duplicate payment.
  • Sub-10 ms latency keeps governance off the critical path. Policy checks, dedup guards and rate limits sit in front of every governed action. They have to be cheap enough that nobody is tempted to skip them.
  • Two delivery contracts, explicitly labelled. Redis documents pub/sub as at-most-once and streams as at-least-once. A governed system needs that distinction stated, not inferred, so that a workflow’s error_policy can be written against a known guarantee.
  • It is the smallest platform in the stack. Redis is a single self-hostable process with no external dependencies, installable from source, packages or Docker. For Mode 3 that matters: fewer moving parts inside the boundary.

Deployment and licensing

Self-hosting. Documented install paths are APT, RPM and Snap on Linux, Homebrew on macOS, Docker (including on Windows), and building from source. Redis Cloud, Redis Enterprise Software and the Redis Enterprise operator for Kubernetes are the commercial deployment options and are not used by Synedrix OS. Replication and Redis Cluster are part of Redis Open Source; Redis Software and Redis Cloud “are closed source and require a commercial license from Redis Ltd.”

Licence — read this carefully. Redis’s licence depends on the version, and changed twice since the canonical stack document was written. Per the official Redis licensing page and the LICENSE.txt in the redis/redis repository:

VersionLicence
Redis 7.2 and earlierBSD 3-Clause
Redis Community Edition 7.4.x – 7.8.xDual: RSALv2 or SSPLv1
Redis Open Source 8.0 and laterTri-licence: RSALv2, SSPLv1, or AGPLv3 — the user selects one

LICENSE.txt states: “Starting with Redis 8, Redis Open Source is moving to a tri-licensing model with all new Redis code contributions governed by the updated Redis Software Grant and Contributor License Agreement”, and confirms that “Redis Open Source 7.2 and prior releases remain subject to the BSDv3 clause license.”

Of the three current options, Redis identifies AGPLv3 as an OSI-approved open source licence, while RSALv2 and SSPLv1 are not open source licences. RSALv2 permits use, copying, distribution and derivative works but prohibits commercialising the software or providing it as a managed service. SSPLv1 requires that anyone offering the product as a service publicly release their modifications and management-layer source under SSPL. AGPLv3 is copyleft with a network clause: modified derivative works must be licensed under AGPLv3 and made available to users of the network service. Redis Ltd. states that “There are no plans to change or add to the current Redis Open Source license configuration.”

Open item. Tech Stack §4 records Redis as “open source under BSD 3-Clause. Redis 7+ recommended”, and Deployment Model Spec repeats “BSD 3-Clause”. That was accurate for Redis 7.2 and earlier only. A stack that pins “Redis 7+” spans three different licences: BSD 3-Clause at 7.2, dual RSALv2/SSPLv1 at 7.4–7.8, and the RSALv2/SSPLv1/AGPLv3 tri-licence at 8.0 and later. Two decisions follow and neither is resolved by this page. First, the version floor must be restated as a licence decision, not a feature decision — “Redis 7+” no longer identifies a licence. Second, if Synedrix OS is to keep its “every component is open source” commitment, the AGPLv3 option under Redis 8+ is the only one of the three that qualifies, and electing it must be recorded explicitly, because the default assumption of “Redis is BSD” is now wrong and both RSALv2 and SSPLv1 carry restrictions that are material to delivering Synedrix OS to a customer as a product. The canonical stack and deployment documents need correcting.

Landscape note. In March 2024 the Linux Foundation announced Valkey, “an open source alternative to the Redis in-memory, NoSQL data store”, which “will continue development on Redis 7.2.4 and will keep the project available for use and distribution under the open source Berkeley Software Distribution (BSD) 3-clause license”. It is recorded here as a fact about the current landscape, not as a recommendation; any evaluation belongs with the licence decision above.

Official documentation

Synedrix OS · Platform reference · Redis