Redis streams are append-only logs stored inside the keyspace. They give Redis a data type for events that need IDs, ordering, replay, and consumer coordination.

At the surface:

XADD orders * item book qty 1
XRANGE orders - +
XREAD STREAMS orders 0

Underneath, the model is:

stream key -> ordered entries -> entry ID -> field-value pairs

That makes streams feel familiar if you know logs, queues, or event systems, but Redis streams have their own compact shape.

IDs Carry Time And Sequence

Stream entry IDs usually look like:

milliseconds-sequence

Examples:

1710000000000-0
1710000000000-1
1710000000001-0

When a client uses *, Redis generates the next ID. The millisecond component usually reflects server time, while the sequence component preserves ordering when multiple entries land in the same millisecond.

IDs are not just labels. They make range queries and incremental reads possible.

Streams Are Not Lists With Timestamps

A Redis list is an ordered sequence that is good at pushing and popping near the ends. Once an item is popped, it is gone.

A stream is an append-only structure with stable IDs. Consumers can ask for entries after a known ID, read ranges, and coordinate through consumer groups.

list:   mutable sequence, simple queue behavior
stream: append-only log, replayable event behavior

That difference changes how applications recover. A worker that disconnects from a stream can resume from an ID. A consumer group can know which messages were delivered but not acknowledged.

Consumer Groups Add Delivery State

Consumer groups turn a stream from a log into a coordinated work distribution mechanism.

A group tracks:

last delivered ID
pending entries
which consumer owns each pending entry

When a consumer reads with XREADGROUP ... STREAMS key >, it asks for entries that have not yet been delivered to that group. When work is finished, XACK removes the entry from the pending set.

This creates a useful middle ground. The stream keeps event history, while the group tracks delivery progress for a set of workers.

Trimming Keeps Streams Bounded

Streams can grow indefinitely unless they are trimmed. Redis supports trimming by length or other criteria:

XTRIM orders MAXLEN 10000

Approximate trimming is often acceptable because it lowers maintenance cost. This is another example of Redis preferring practical bounded work over perfect bookkeeping when exactness is not essential.

Streams In The Redis Family

The relationship among Redis messaging tools becomes clear when viewed by durability and coordination:

Pub/Sub: live broadcast, no replay
List: simple queue, items removed by consumption
Stream: durable ordered log with IDs
Stream + group: log plus coordinated delivery tracking

Streams do not replace all queues or brokers, but they fill an important gap inside Redis. They let the database store the event history, expose it through range-friendly IDs, and coordinate consumers without abandoning Redis' command-driven model.