Questions
4 of 5
Basics
Cluster Architecture
Topics, Partitions and Records
Producers
Consumers
Consumer Groups
Offset Management
Replication and Fault Tolerance
Storage Internals
Networking and Request Processing
Performance and Throughput
Delivery Semantics
Transactions
Kafka Streams
Kafka Connect
Schema and Serialization
Security
Error Handling and Retry Patterns
Ordering and Partitioning Design
Testing
Monitoring and Observability
Debugging and Troubleshooting
Deployment and Operations
Admin and CLI Operations
Reliability and Disaster Recovery
Integration Patterns
Modern Kafka Architecture
Advanced Internals
Scalability and Capacity Planning
Architecture and System Design
Production Best Practices
Expert Edge Cases
Versioning and Upgrades
Admin and CLI Operations
Senior End-to-End Scenarios
Difficulty: 8/10
Commit and replay
Replay with an isolated group.id or by resetting only the target group's offsets, since offsets are per group and other groups are unaffected
Because committed offsets are stored per group, replay is naturally isolated: changing one group's position never touches another group's. That gives me two clean options. Option one is a dedicated replay group: start a separate application or job with a new group.id and seek it to the chosen starting point. It cannot disturb the production group, it can be throttled and stopped independently, and the production group keeps its position. Option two is resetting the production group itself with kafka-consumer-groups.sh --reset-offsets, which is appropriate when that same service needs to reprocess (for example after a bug fix), but the group must have no active members while the reset executes, and the reset rewinds only that group.
The starting point can be the earliest offset, a specific offset, a shift relative to the current offset, or a timestamp. Timestamp-based resets resolve to the earliest offset whose record timestamp is at or after the time, via offsetsForTimes. The checks that matter more than the mechanics are these. Is the data still there? Replay is limited by retention, and compacted topics only retain the latest value per key. What happens downstream? A replay re-triggers every side effect, so handlers must be idempotent or write to a separate sink. Is the cluster protected? Reading old data comes from disk rather than page cache, which can hurt broker latency for other clients, so apply a consumer fetch quota to the replay client and run it off-peak.
javascript
javascript
- 1
Trade-off: a separate replay group is safest and cleanly separable, but if the same service must reprocess, you eventually reset the real group, which requires stopping it and coordinating the cutover.
- 2
Trade-off: manual assign() with seek avoids group coordination and rebalances during replay, but gives no automatic failover. For a one-off job that is acceptable.
- 3
Common mistake: resetting offsets while consumers are running. The tool refuses for active groups, and forcing the situation by restarting consumers mid-reset causes confusing results.
- 4
Common mistake: forgetting that a reset rewinds the group for the specified topics only. Other topics the group subscribes to are untouched unless you pass --all-topics.
- 5
Common mistake: replaying into production side effects (emails, payments, webhooks). Replay to a sink that is safe, or make every handler idempotent, and dry-run before executing.
- 6
Common mistake: replaying data that no longer exists. Verify retention, log start offsets and compaction before promising a replay window. Tiered storage can extend history, but check your version and configuration.
- 7
Operational note: record the replay window, the resulting offsets and the owner. After finishing, delete the temporary group so it does not linger with stale offsets and lag alerts.
- 8
Version note: reset tooling and flags are stable across modern versions, but behavior of group state and describe output differs slightly under the KIP-848 protocol. Verify that the group is truly empty before executing a reset.
Scenario Questions
0-2 years experience
2-5 years experience
- 1A bug in the billing consumer corrupted data for the last 6 hours. Describe step by step how you rewind that group to six hours ago, including what must be true before you run the reset.
- 2The reset command reports it cannot proceed because the group is active. What are your options and which would you choose?
5-8 years experience
8+ years experience
- 1Design a self-service replay platform for 100 teams: who can trigger replays, how topics and windows are validated against retention, how load is capped, and how side effects and audits are handled.
- 2The business asks to replay events from 45 days ago, but topic retention is 7 days. What are your options for recovering that history and what are the correctness risks of each?