Consumer Groups
debt(d7/e5/b5/t5)
Closest to 'only careful code review or runtime testing' (d7). The term's detection_hints show automated=no, and the code pattern 'group.id|consumer_group' is just a string match. There are no automated tools listed that detect consumer group misconfiguration (like having more consumers than partitions). Issues like idle consumers or rebalancing problems only surface during runtime load testing or production monitoring when throughput doesn't scale as expected.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix mentions configuring separate consumer groups for independent pipelines, scaling consumers, and tuning session.timeout.ms/heartbeat.interval.ms. Fixing misconfigured consumer groups requires changes to consumer configuration, potentially infrastructure/deployment changes to adjust consumer counts, and code changes to handle rebalancing gracefully—spanning multiple files and configuration layers within the messaging component.
Closest to 'persistent productivity tax' (b5). Consumer group configuration decisions affect all queue-worker contexts (per applies_to). The choice of how many partitions and consumer groups to use shapes ongoing scaling decisions, deployment topology, and monitoring approaches. While not system-defining, it creates a persistent tax on the messaging subsystem that affects throughput planning and operational practices across work streams.
Closest to 'notable trap' (t5). The misconception clearly states 'More consumers always means more throughput' — this is a documented gotcha that most developers eventually learn but initially get wrong. The partition-count ceiling on useful consumers contradicts the intuition from other scaling patterns where 'more workers = more throughput' holds true. It's a well-known Kafka gotcha but not catastrophic since the excess consumers just idle rather than causing data loss.
TL;DR
Explanation
Kafka consumer group: each partition assigned to exactly one consumer in the group. Adding consumers = more parallelism (up to partition count). Each group maintains independent offsets — multiple groups each process all messages independently. Use cases: one group for email, another for analytics, another for audit — all receive all events. Rebalancing: partitions reassigned when consumers join/leave — brief pause. RabbitMQ: consumer groups not native but queue can have multiple consumers (competing consumers = one processes each message). Redis Streams: XREADGROUP supports consumer groups with acknowledgement.
Common Misconception
Why It Matters
Common Mistakes
- More consumers than partitions — excess consumers idle.
- Not handling partition rebalancing gracefully — in-flight processing may be interrupted.
- Using one consumer group for all uses — should be separate groups for independent processing.
Code Examples
// Same consumer group for email AND analytics — only one gets each message:
$consumer->subscribe(['orders'], ['group.id' => 'all-consumers']); // Wrong// Separate groups — both get all messages:
// Email service:
$emailConsumer->subscribe(['orders'], ['group.id' => 'email-service']);
// Analytics service:
$analyticsConsumer->subscribe(['orders'], ['group.id' => 'analytics-service']);
// Scale email: add more consumers (up to partition count)
$emailConsumer2->subscribe(['orders'], ['group.id' => 'email-service']);