Resource planning and capacity in Kafka - Time & Space Complexity
When working with Kafka, resource planning and capacity affect how fast and smoothly data flows through the system.
We want to understand how the time to process messages grows as the number of messages or partitions increases.
Analyze the time complexity of the following Kafka consumer processing loop.
// Kafka consumer polling loop
while (true) {
ConsumerRecords records = consumer.poll(Duration.ofMillis(100));
for (ConsumerRecord record : records) {
process(record);
}
}
This code continuously polls Kafka for new messages and processes each message one by one.
Look at what repeats as input grows.
- Primary operation: Loop over all messages received in each poll.
- How many times: Once per message in the batch, repeated every poll cycle.
As the number of messages per poll increases, the processing time grows proportionally.
| Input Size (messages per poll) | Approx. Operations |
|---|---|
| 10 | 10 process calls |
| 100 | 100 process calls |
| 1000 | 1000 process calls |
Pattern observation: Processing time grows linearly with the number of messages.
Time Complexity: O(n)
This means the time to process messages grows directly in proportion to how many messages arrive.
[X] Wrong: "Processing time stays the same no matter how many messages arrive."
[OK] Correct: Each message needs its own processing time, so more messages mean more total work.
Understanding how processing time scales with message volume helps you design systems that handle load smoothly and predict performance.
"What if we batch process messages instead of one by one? How would the time complexity change?"
Practice
Solution
Step 1: Understand resource planning purpose
Resource planning is about preparing Kafka to manage data efficiently without delays or failures.Step 2: Identify the main goal
The main goal is to handle the expected data load smoothly, avoiding bottlenecks or crashes.Final Answer:
To ensure Kafka can handle the expected data load smoothly -> Option DQuick Check:
Resource planning = handle data load smoothly [OK]
- Confusing resource planning with limiting users
- Thinking it reduces topics or message sizes
- Ignoring the data load aspect
Solution
Step 1: Review capacity factors in Kafka
Capacity depends on brokers, partitions, and hardware resources.Step 2: Identify correct capacity increase method
Adding more brokers increases cluster capacity by distributing load.Final Answer:
Add more brokers to the Kafka cluster -> Option AQuick Check:
More brokers = more capacity [OK]
- Thinking decreasing partitions increases capacity
- Reducing hardware lowers capacity
- Limiting consumers does not increase capacity
Solution
Step 1: Understand partition increase effect
Increasing partitions without adding brokers means more load per broker.Step 2: Analyze cluster behavior
Kafka does not auto-add brokers; load per broker rises, risking performance issues.Final Answer:
The load per broker increases, possibly causing performance issues -> Option CQuick Check:
More partitions + same brokers = more load per broker [OK]
- Assuming Kafka auto-adds brokers
- Thinking consumers must be reduced
- Believing Kafka rejects partition increase
Solution
Step 1: Understand load distribution in Kafka
Partitions are assigned to brokers; uneven distribution causes load imbalance.Step 2: Identify cause of high CPU on one broker
Uneven partition assignment can overload one broker, causing high CPU usage.Final Answer:
Uneven partition distribution causing load imbalance -> Option AQuick Check:
Uneven partitions = uneven CPU load [OK]
- Assuming Kafka balances CPU automatically
- Blaming hardware without checking partitions
- Thinking all brokers always have equal load
Solution
Step 1: Analyze message load requirements
1 million messages per second is very high; needs many brokers and partitions.Step 2: Choose hardware and partition setup
High-performance SSDs and many brokers with many partitions support high throughput and reliability.Final Answer:
10 brokers with 100 partitions each and high-performance SSD storage -> Option BQuick Check:
High load needs many brokers, partitions, and fast storage [OK]
- Choosing too few brokers or partitions
- Ignoring storage speed impact
- Not planning for replication and reliability
Ready to prove it?
Pass the test and this pattern moves unknown
