📖 Scenario: You work in a company that uses Apache Kafka to handle messages between different services. You want to plan how many partitions each topic should have to handle the expected load without delays.
🎯 Goal: Build a simple Kafka resource planner that calculates the total capacity needed based on the number of topics and partitions, and then outputs the total capacity.
📋 What You'll Learn
Create a dictionary called topics with topic names as keys and number of partitions as values
Create a variable called capacity_per_partition that holds the capacity value per partition
Calculate the total capacity by multiplying partitions by capacity per partition for all topics using a comprehension
Print the total capacity with a descriptive message
💡 Why This Matters
🌍 Real World
Kafka is widely used for messaging in distributed systems. Planning partitions and capacity helps avoid bottlenecks and ensures smooth data flow.
💼 Career
Understanding resource planning in Kafka is important for roles like DevOps engineers, backend developers, and system architects who manage scalable data pipelines.
Progress0 / 4 steps
1
Create the topics dictionary
Create a dictionary called topics with these exact entries: 'orders': 3, 'payments': 2, 'shipments': 4
Kafka
Hint
Use curly braces to create a dictionary with keys and values separated by colons.
2
Set capacity per partition
Create a variable called capacity_per_partition and set it to 1000 to represent capacity units per partition
Kafka
Hint
Just assign the number 1000 to the variable capacity_per_partition.
3
Calculate total capacity
Create a variable called total_capacity that calculates the sum of partitions times capacity_per_partition for all topics using a comprehension with for partitions in topics.values()
Kafka
Hint
Use sum() with a generator expression multiplying each partitions value by capacity_per_partition.
4
Print the total capacity
Write a print statement that outputs: Total capacity needed: {total_capacity} using an f-string
Kafka
Hint
Use print() with an f-string to show the total_capacity variable.
Practice
(1/5)
1. What is the main goal of resource planning in Kafka?
easy
A. To reduce the number of topics in Kafka
B. To increase the size of Kafka messages
C. To limit the number of users accessing Kafka
D. To ensure Kafka can handle the expected data load smoothly
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 D
Quick Check:
Resource planning = handle data load smoothly [OK]
Hint: Resource planning means handling data load well [OK]
Common Mistakes:
Confusing resource planning with limiting users
Thinking it reduces topics or message sizes
Ignoring the data load aspect
2. Which of the following is the correct way to increase Kafka capacity?
easy
A. Add more brokers to the Kafka cluster
B. Decrease the number of partitions per topic
C. Reduce the hardware resources of brokers
D. Limit the number of consumers
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 A
Quick Check:
More brokers = more capacity [OK]
Hint: Add brokers to increase capacity [OK]
Common Mistakes:
Thinking decreasing partitions increases capacity
Reducing hardware lowers capacity
Limiting consumers does not increase capacity
3. Given a Kafka cluster with 3 brokers and 6 partitions per topic, what happens if you increase partitions to 12 without adding brokers?
medium
A. The number of consumers must be reduced
B. The cluster automatically adds brokers to handle the load
C. The load per broker increases, possibly causing performance issues
D. Kafka will reject the partition increase request
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 C
Quick Check:
More partitions + same brokers = more load per broker [OK]
Hint: More partitions without brokers = more load per broker [OK]
Common Mistakes:
Assuming Kafka auto-adds brokers
Thinking consumers must be reduced
Believing Kafka rejects partition increase
4. You have a Kafka cluster with 5 brokers but notice high CPU usage on one broker only. What is the likely cause?
medium
A. Uneven partition distribution causing load imbalance
B. All brokers have equal load by design
C. Kafka automatically balances CPU usage evenly
D. The broker hardware is faulty and cannot be fixed
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 A
Quick Check:
Uneven partitions = uneven CPU load [OK]
Hint: Check partition distribution for load imbalance [OK]
Common Mistakes:
Assuming Kafka balances CPU automatically
Blaming hardware without checking partitions
Thinking all brokers always have equal load
5. You want to plan capacity for a Kafka cluster expected to handle 1 million messages per second. Which combination is best to start with?
hard
A. 5 brokers with 5 partitions each and low memory hardware
B. 10 brokers with 100 partitions each and high-performance SSD storage
C. 2 brokers with 10 partitions each and standard HDD storage
D. 1 broker with 200 partitions and no replication
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 B
Quick Check:
High load needs many brokers, partitions, and fast storage [OK]
Hint: High load needs many brokers, partitions, and SSDs [OK]
Common Mistakes:
Choosing too few brokers or partitions
Ignoring storage speed impact
Not planning for replication and reliability
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.