Kafka incidents rarely start with Kafka being broken. More often, the failure is in consumer group design, retry behavior, database writes, payload size, or the assumptions around idempotency.
This hub groups the Bytz Echo Kafka articles by the kind of production signal engineers usually see first: duplicate work, stuck consumers, lag, and confusing monitoring.
Duplicate work and consumer group mistakes
- Kafka Wasn?t Broken. We Reused the Same Consumer Group ID – a real example of group ID reuse causing confusing consumer behavior.
- Why Spring Boot Kafka Consumers Generate Duplicate Reports – how duplicate report generation appears when consumer behavior is misunderstood.
- Spring Boot Kafka Producer and Consumer Setup That Avoids Duplicate Messages – setup notes for producer and consumer boundaries.
Lag, writes, and throughput
- Kafka Lag vs PostgreSQL Writes: What Slowed the Consumer Down – a benchmark where database writes affected lag and drain time.
- JPA vs JDBC Performance ? 10M Rows (PostgreSQL) – useful context when Kafka consumers write through ORM layers.
Local infrastructure and schema
- Kafka Server on Docker with WebUI for Monitoring – a practical local stack for inspecting topics and consumers.
- Spring Boot Tutorial with Kafka and Apache Avro Integration – schema-based messaging for teams that need stronger contracts.
How to read these stories
Start with the incident article that matches your symptom. If the symptom is duplicate work, read the consumer group and duplicate report articles first. If the symptom is lag, start with the PostgreSQL write benchmark before changing Kafka broker settings.
Suggested next articles
- Kafka Retry Strategy That Prevented Duplicate Jobs
- Why Consumer Lag Increased After We Added an Index
- Spring Boot Kafka Dead Letter Topics: What We Got Wrong First