Event Stream
An append-only, retained log of events that many independent consumers read at their own position, and can re-read.
The distinguishing property against a queue is retention plus independent offsets. The log keeps events for a configured period; each consumer group tracks where it has read; a new consumer can start from the beginning and rebuild its state from history. That is what makes streams the substrate for CQRS read models, CDC pipelines and analytics.
Consequences worth designing for: ordering is guaranteed only within a partition, so the partition key decides what is ordered — key by entity ID if per-entity ordering matters. Consumer parallelism is capped by partition count, which is awkward to change later. And retention is a real cost decision, since "keep everything forever" is a storage bill.
The trap is treating a stream as a queue with better marketing. If you never re-read and never add consumers, you are paying operational complexity for capability you do not use.