Questions
2 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: 5/10
Partition reassignment, Broker balancing, Replica placement
Partition reassignment: reasons, risks, and safeguards
I reassign partitions when replica placement no longer meets operational goals, such as balancing disk usage, decommissioning a broker, improving rack-aware placement, or addressing capacity changes. Reassignment changes which brokers host replicas; it is not the same as increasing a topic's partition count. The main risk is replica data movement consuming network and disk resources while production traffic continues. I review the target layout, validate capacity, throttle movement where supported, and monitor client impact.
javascript
- 1
Common reasons include balancing storage and replicas, removing a broker, improving rack awareness, and adapting to capacity changes.
- 2
Check destination disk headroom, network capacity, broker health, replication factor, rack placement, and replica sizes before execution.
- 3
Replica movement can increase disk I/O and network traffic, elevate request latency, and temporarily increase replication lag.
- 4
Use a reviewed plan and small batches. Apply throttles supported by the installed Kafka version and adjust based on observed impact.
- 5
Monitor under-replicated partitions, ISR changes, disk utilization, network throughput, produce/fetch latency, and consumer lag.
- 6
Common misconception: reassignment is only a metadata change. Existing replica data often needs to be copied; command options vary by Kafka version.
Scenario Questions
0-2 years experience
2-5 years experience
5-8 years experience
8+ years experience
- 1One broker is nearly out of disk while others are lightly utilized. How would you plan a safe reassignment? How would you automate and govern this process?
- 2A reassignment is progressing, but consumer latency is rising. What would you inspect and which controls could help? How would you recover safely from a partial failure?