Consumer Group
A set of consumers that cooperatively read one stream, with each partition assigned to exactly one member, so the group collectively processes every message once.
The abstraction that gives an event stream both broadcast and work-distribution semantics at once. Each group receives every message in the stream; within a group, each partition is assigned to exactly one consumer, so members share the work.
Two consequences follow directly and account for most operational surprises.
Parallelism is capped by partition count. Ten partitions means at most ten useful consumers in a group; an eleventh sits idle. Since partition count is awkward to increase later — it changes which key lands where — this is a capacity decision made at design time.
Rebalancing is disruptive. When a member joins, leaves or is presumed dead, partitions are reassigned and, in the classic protocol, processing stops group-wide while that happens. A consumer whose processing occasionally exceeds the poll interval is ejected, triggering a rebalance, which slows everyone, which causes more ejections. Cooperative and incremental rebalancing protocols exist specifically to reduce this.
Groups are also how you add a new consumer safely: a new group ID reads the whole retained history without affecting any existing consumer.