Reference · built on requestConnectorDatabases & warehouses

Redis

Keys, stream entries, and keyspace notifications from Redis over RESP on port 6379, with consumer groups for once-per-group delivery.

Request accessPricing ↗

About

Redis is an in-memory data store from Redis, run as Redis Open Source or Redis Cloud. Clients open a TCP connection to port 6379 and speak RESP, the Redis serialization protocol; RESP2 is the default and a HELLO 3 handshake upgrades a connection to RESP3. Streams, added in Redis 5.0, are append-only logs with entry IDs of the form millisecondsTime-sequenceNumber, read with XREAD or XREADGROUP and acknowledged with XACK. Keyspace notifications, off by default, publish key-space and key-event messages on __keyspace@<db>__ and __keyevent@<db>__ channels once notify-keyspace-events is set.

An operator on Fibric reads the keys and streams an ACL user allows and proposes writes for your approval, with a receipt for each change.

This is a reference listing. It documents what Fibric would read from Redis and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Values of keys matching the ACL key patterns granted to the user, through GET, HGETALL, and each type's read commands
  • Stream entries by ID range with XRANGE, or new entries with XREAD BLOCK from the $ position
  • Entries delivered to a consumer group with XREADGROUP using the > ID, tracked in the pending entries list until XACK
  • Keyspace and key-event notifications on Pub/Sub channels, enabled by notify-keyspace-events flags such as KEA
  • Pending and unclaimed entries with XPENDING, reclaimed after an idle time with XAUTOCLAIM
  • Server details from the HELLO reply: version, mode, and role

Proposed actions

  • Target capability: propose XADD of an entry to a named stream after approval, with MAXLEN trimming set in the proposal
  • Target capability: propose SET or HSET on a key the ACL user may write
  • Target capability: propose PUBLISH of a message on a channel the user's &pattern allows

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Turn a job stream into approvals

    Read the fulfillment stream as a consumer group, hold each entry pending until a person approves the proposed action, then XACK it.

    With Order Risk, Exception Routing

  • Notice a queue backing up

    Watch XLEN and XPENDING for the work stream and raise a notice when the unacknowledged count climbs past the level you set.

    With Anomaly Notice, Integration Health

  • React to keys that expire

    Subscribe to __keyevent@0__:expired and treat an expiring hold or session key as a prompt to check the record behind it.

    With Pickup Expiry, Cancellation Window

Requirements

  • A Redis server at version 6 or later for ACL users and RESP3; Streams need Redis 5.0
  • An ACL user granted +@read and +@stream with ~pattern key rules, and +@write only for proposed writes
  • notify-keyspace-events set to a non-empty string containing K or E, for keyspace notifications
  • Network reach to port 6379, or a TLS port, from the deployment; protected mode rejects non-loopback connections otherwise
Authentication
An ACL user created with ACL SETUSER, authenticated by AUTH username password or HELLO 3 AUTH, limited to command categories, key patterns, and channel patterns.

Limits

  • Pub/Sub and keyspace notifications are at-most-once; events sent while a subscriber is disconnected are lost
  • Expired events fire when Redis deletes the key, which can lag the TTL reaching zero
  • In a cluster, keyspace events are node-specific, so a reader must subscribe on every node
  • Stream consumers must dedupe: an entry stays pending until XACK and can be redelivered or reclaimed

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Redis ↗

Questions and answers

Are keyspace notifications reliable?
No. Redis documents them as fire and forget over Pub/Sub: if the subscriber disconnects, events sent in the meantime are lost. For delivery that survives a disconnect, write events to a stream and read it with a consumer group.
What does a consumer group guarantee?
Each entry goes to one consumer in the group and stays in the pending entries list until XACK. Unacknowledged entries can be inspected with XPENDING and reassigned with XCLAIM or XAUTOCLAIM, so processing is at least once.
Which Redis version does the connector need?
Streams arrived in Redis 5.0, ACL users and RESP3 in Redis 6.0, and XAUTOCLAIM in 6.2. Channel permissions with &pattern came in 6.2, and from 7.0 new ACL users get no channels by default.
Ask about Redis

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Redis through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy