{
  "id": "streaming",
  "title": "Redis streaming",
  "url": "https://redis.io/docs/latest/develop/use-cases/streaming/",
  "summary": "Process ordered event streams with consumer groups, replay, and configurable retention.",
  "tags": [
    "docs",
    "develop",
    "stack",
    "oss",
    "rs",
    "rc"
  ],
  "last_updated": "2026-05-26T09:29:27-05:00",
  "children": [
    {
      "id": "redis-py",
      "summary": "Implement a Redis event-streaming pipeline in Python with redis-py",
      "title": "Redis streaming with redis-py",
      "url": "https://redis.io/docs/latest/develop/use-cases/streaming/redis-py/"
    },
    {
      "id": "nodejs",
      "summary": "Implement a Redis event-streaming pipeline in Node.js with node-redis",
      "title": "Redis streaming with node-redis",
      "url": "https://redis.io/docs/latest/develop/use-cases/streaming/nodejs/"
    },
    {
      "id": "go",
      "summary": "Implement a Redis event-streaming pipeline in Go with go-redis",
      "title": "Redis streaming with go-redis",
      "url": "https://redis.io/docs/latest/develop/use-cases/streaming/go/"
    },
    {
      "id": "java-jedis",
      "summary": "Implement a Redis event-streaming pipeline in Java with Jedis",
      "title": "Redis streaming with Jedis",
      "url": "https://redis.io/docs/latest/develop/use-cases/streaming/java-jedis/"
    },
    {
      "id": "java-lettuce",
      "summary": "Implement a Redis event-streaming pipeline in Java with Lettuce",
      "title": "Redis streaming with Lettuce",
      "url": "https://redis.io/docs/latest/develop/use-cases/streaming/java-lettuce/"
    },
    {
      "id": "dotnet",
      "summary": "Implement a Redis event-streaming pipeline in C# with StackExchange.Redis",
      "title": "Redis streaming with StackExchange.Redis",
      "url": "https://redis.io/docs/latest/develop/use-cases/streaming/dotnet/"
    },
    {
      "id": "php",
      "summary": "Implement a Redis event-streaming pipeline in PHP with Predis",
      "title": "Redis streaming with Predis",
      "url": "https://redis.io/docs/latest/develop/use-cases/streaming/php/"
    },
    {
      "id": "ruby",
      "summary": "Implement a Redis event-streaming pipeline in Ruby with redis-rb",
      "title": "Redis streaming with redis-rb",
      "url": "https://redis.io/docs/latest/develop/use-cases/streaming/ruby/"
    },
    {
      "id": "rust",
      "summary": "Implement a Redis event-streaming pipeline in Rust with redis-rs",
      "title": "Redis streaming with redis-rs",
      "url": "https://redis.io/docs/latest/develop/use-cases/streaming/rust/"
    }
  ],
  "page_type": "content",
  "content_hash": "fc2231939cd21b26d30b98bc63ddc1b8ad8721cfc5a7a4fdbaa237cb88da1dc8",
  "sections": [
    {
      "id": "when-to-use-redis-streaming",
      "title": "When to use Redis streaming",
      "role": "overview",
      "text": "Use Redis streaming when you need to process and deliver ordered event streams — user actions, telemetry, transactions, inter-service messages — with consumer groups, replay, and configurable retention, without standing up a dedicated streaming platform."
    },
    {
      "id": "why-the-problem-is-hard",
      "title": "Why the problem is hard",
      "role": "content",
      "text": "Continuous event flows pushed through primary databases or ad-hoc queues add latency on the request path, make backpressure hard to control, and tightly couple producers to consumers. Some of the obvious workarounds have real drawbacks:\n\n-   **A dedicated streaming platform** (Kafka, Pulsar) solves all of this but adds significant\n    operational overhead — separate clusters, partition management, consumer rebalancing — that's\n    disproportionate when retention windows are hours or days, not months.\n-   **Pub/sub** ([Redis Pub/Sub](https://redis.io/docs/latest/develop/pubsub), MQTT) is fire-and-forget\n    transport: messages are delivered to whoever is connected and discarded, with no persistence,\n    replay, or consumer tracking.\n-   **Polling a primary database for new rows** generates constant load on the system of record,\n    struggles to order events from concurrent writers, and offers no replay or per-consumer cursor.\n\nA workable streaming layer needs an ordered, durable log, independent consumer tracking with\nacknowledgment, at-least-once delivery, and retention controls — all without introducing a\nseparate broker for moderate-scale workloads.\n\nThis pattern is distinct from [pub/sub](https://redis.io/docs/latest/develop/use-cases/pub-sub), which is\nat-most-once transport with no history: a subscriber that's offline when a message is published\nmisses it for good. It is also distinct from a\n[job queue](https://redis.io/docs/latest/develop/use-cases/job-queue), where each task is claimed by exactly\none worker and discarded after it completes. Streaming retains the ordered history, so many\nindependent consumer groups can read the same events at their own pace and replay from any point."
    },
    {
      "id": "what-you-can-expect-from-a-redis-solution",
      "title": "What you can expect from a Redis solution",
      "role": "content",
      "text": "You can:\n\n-   Deliver ordered events to multiple independent consumer groups, each processing the full\n    stream at its own pace.\n-   Scale consumers horizontally within a group to share work across workers, with at-least-once\n    delivery and per-consumer tracking.\n-   Replay historical events for debugging, bootstrapping a new projection, or rebuilding a\n    downstream system from scratch.\n-   Bound memory by retaining events by length or by minimum ID, without a separate cleanup job.\n-   Recover unacknowledged entries from crashed consumers, so a worker dying mid-message does not\n    silently lose work (entries trimmed by `MAXLEN ~` before they are acked are surfaced in\n    `XAUTOCLAIM`'s deleted-IDs list, so the caller can route them to a dead-letter store rather\n    than retry against a missing payload).\n-   Partition streams by tenant, region, or entity for load distribution and per-entity event\n    sourcing.\n-   Replace a dedicated Kafka deployment for moderate-scale, short-retention streaming workloads\n    using infrastructure you already run."
    },
    {
      "id": "how-redis-supports-the-solution",
      "title": "How Redis supports the solution",
      "role": "content",
      "text": "In practice, producers append events to a stream with\n[`XADD`](https://redis.io/docs/latest/commands/xadd) and Redis assigns each entry an auto-generated,\ntime-ordered ID. Consumers either read the stream directly with\n[`XREAD`](https://redis.io/docs/latest/commands/xread), or join a *consumer group* and read with\n[`XREADGROUP`](https://redis.io/docs/latest/commands/xreadgroup). Each consumer gets its own\npending-entries list of in-flight messages, while the group as a whole tracks a single\n`last-delivered-id` cursor that advances as entries are handed out to any consumer. Once a consumer finishes processing an\nentry, it acknowledges it with [`XACK`](https://redis.io/docs/latest/commands/xack); entries left\nunacknowledged past a timeout can be reassigned to a healthy consumer with\n[`XCLAIM`](https://redis.io/docs/latest/commands/xclaim) or\n[`XAUTOCLAIM`](https://redis.io/docs/latest/commands/xautoclaim).\n\nRedis provides the following features that make it a good fit for streaming:\n\n-   [Streams](https://redis.io/docs/latest/develop/data-types/streams)\n    ([`XADD`](https://redis.io/docs/latest/commands/xadd),\n    [`XLEN`](https://redis.io/docs/latest/commands/xlen)) provide an append-only log with auto-generated\n    time-ordered IDs, so ordering is intrinsic to the data structure rather than something the\n    application has to maintain.\n-   [Consumer groups](https://redis.io/docs/latest/develop/data-types/streams#consumer-groups)\n    ([`XREADGROUP`](https://redis.io/docs/latest/commands/xreadgroup),\n    [`XACK`](https://redis.io/docs/latest/commands/xack)) give at-least-once delivery with per-consumer\n    cursors and acknowledgment, so workers in a group share the stream's work and multiple groups\n    read the same stream independently.\n-   [`XRANGE`](https://redis.io/docs/latest/commands/xrange) and\n    [`XREVRANGE`](https://redis.io/docs/latest/commands/xrevrange) support replay and range queries —\n    bootstrap a new projection from the start of the stream, audit recent events, or run\n    point-in-time reads by ID range.\n-   [`XPENDING`](https://redis.io/docs/latest/commands/xpending),\n    [`XCLAIM`](https://redis.io/docs/latest/commands/xclaim), and\n    [`XAUTOCLAIM`](https://redis.io/docs/latest/commands/xautoclaim) recover messages a crashed consumer\n    left in flight, so no event sits invisibly past its processing window.\n-   Retention controls — [`XADD ... MAXLEN ~ n`](https://redis.io/docs/latest/commands/xadd) and\n    [`XTRIM MINID ~ id`](https://redis.io/docs/latest/commands/xtrim) — bound stream size by length or by\n    oldest event, so memory stays bounded as the stream rolls forward.\n-   Sub-millisecond reads and writes from memory, so streaming runs on the same Redis instance\n    already handling cache, sessions, or rate limiting at zero marginal cost."
    },
    {
      "id": "ecosystem",
      "title": "Ecosystem",
      "role": "content",
      "text": "The following libraries and frameworks use Redis Streams for event-driven workloads:\n\n-   **Java**:\n    [Spring Data Redis Streams](https://docs.spring.io/spring-data/redis/reference/redis/redis-streams.html)\n    for consumer-group processing with producer/consumer abstractions and pending-entries handling.\n-   **Node.js**: [`node-redis`](https://github.com/redis/node-redis) and\n    [`ioredis`](https://github.com/redis/ioredis) for stream producers and consumers in\n    event-driven APIs.\n-   **Python**: [`redis-py`](https://redis.readthedocs.io/) with\n    [FastAPI](https://fastapi.tiangolo.com/) or [Django](https://www.djangoproject.com/) for\n    microservice event pipelines.\n-   **Infrastructure**:\n    [Active-Active geo-distribution](https://redis.io/docs/latest/operate/rs/databases/active-active) on\n    Redis Enterprise / Redis Cloud for cross-region stream replication;\n    [Azure Managed Redis](https://azure.microsoft.com/en-us/products/managed-redis) with\n    [Azure Functions](https://azure.microsoft.com/en-us/products/functions) for serverless event\n    backbones."
    },
    {
      "id": "code-examples-to-build-your-own-redis-streaming-pipeline",
      "title": "Code examples to build your own Redis streaming pipeline",
      "role": "example",
      "text": "The following guides show how to build a simple Redis-backed event stream with producers and\nconsumer groups. Each guide includes a runnable interactive demo that lets you produce events,\nscale consumers within a group, replay history from any point, and watch independent groups\nread the same stream at their own pace.\n\n* [redis-py (Python)](https://redis.io/docs/latest/develop/use-cases/streaming/redis-py)\n* [node-redis (Node.js)](https://redis.io/docs/latest/develop/use-cases/streaming/nodejs)\n* [go-redis (Go)](https://redis.io/docs/latest/develop/use-cases/streaming/go)\n* [Jedis (Java)](https://redis.io/docs/latest/develop/use-cases/streaming/java-jedis)\n* [Lettuce (Java)](https://redis.io/docs/latest/develop/use-cases/streaming/java-lettuce)\n* [StackExchange.Redis (C#)](https://redis.io/docs/latest/develop/use-cases/streaming/dotnet)\n* [Predis (PHP)](https://redis.io/docs/latest/develop/use-cases/streaming/php)\n* [redis-rb (Ruby)](https://redis.io/docs/latest/develop/use-cases/streaming/ruby)\n* [redis-rs (Rust)](https://redis.io/docs/latest/develop/use-cases/streaming/rust)"
    }
  ],
  "examples": []
}