Consumer groups

Model (fan-out, non-Kafka)

• One group = one stream + N members (independent checkpoints).
• Each member receives events where global_position % N == member_index.
• Member index is derived from sorted member IDs (stable ordering).
• Each member maps to one durable subscription (groupID:memberID).

This is fan-out: every event is handled by exactly one member.

vs competing consumers

	Fan-out group	Competing on one subscription_id
Goal	partition workload	scale one handler
Delivery	each event once across group	each event once across pullers
Checkpoint	per member	shared subscription checkpoint

See Durable subscriptions.

Rebalance

On join/leave:

1. Recompute N and member indices.
2. Update each member subscription’s MemberIndex / MemberCount.
3. Members whose partition changed reset checkpoint via replay from partition start.

Persistence

data/subscriptions/groups/<groupID>.json — survives restart.

Legacy monolithic groups.json is migrated on load.

API

gRPC: CreateConsumerGroup, ListConsumerGroups, JoinConsumerGroup, LeaveConsumerGroup, GetConsumerGroup.

CLI: chronacta consumer-group create|join|leave|list|get.

Not supported

• Kafka-compatible consumer protocol
• Cross-stream groups
• Dynamic partition count without rebalance