Suppose a price-update service and a sales-analytics service both need every price change. Give each service a different `group.id`: each consumer group reads the topic independently and keeps its own offsets. Give multiple instances of the same service the same `group.id` so they form one group and share the partitions. section 9.4.1 section 4.2.2
Within a group, at most one consumer reads a given partition at a time. This lets instances divide the work without losing the partition’s ordering guarantee. Consumers in the group write offsets to Kafka, allowing a stopped consumer to resume where the group left off. Kafka brokers help coordinate partition assignment among members. section 4.2.2 section 9.4.1
Start and inspect a price-monitoring group
Start a consumer with `kafka-console-consumer.sh --topic products.prices-offsets --bootstrap-server localhost:9092 --group products.prices.monitoring --from-beginning`. The `--group` option supplies the group ID. Inspect its position with `kafka-consumer-groups.sh --group products.prices.monitoring --describe --bootstrap-server localhost:9092`. The resulting per-partition rows show current offset, log end offset and lag. If new messages arrive while the consumer is stopped, lag grows; restarting the consumer lets it read those messages. section 9.3.2
Choose group IDs deliberately. Accidentally reusing another consumer’s ID can make the consumers share or overwrite offsets, causing messages to be consumed by the wrong service or producing processing inconsistencies. Do not confuse the group ID with `client.id`, which is useful for logging, metrics and tracking. section 9.3.2
