Kafka / Event Stream Partition Calculator
A deterministic tool for calculating the minimum safe partition count for a Kafka topic based on producer and consumer throughput targets.
Run Partition Calculator
Inputs stay in this browser and results are not saved.
Accuracy contract: The max(target/producer, target/consumer) arithmetic is deterministic, but it is only a throughput lower bound and depends on representative benchmarks.
Defined calculation contract
Calculation result
Planning result
The throughput formula gives a minimum of 25 partitions for the supplied 500 MB/s target. It is not a complete topic-sizing recommendation.
Use benchmarked per-partition producer and consumer rates. Then separately check key skew, ordering requirements, consumer-group concurrency, replication, broker limits, failure recovery, and expected growth before choosing the final count.
Versioned sources
Who this Lab is for
Designed for
- Data and backend engineers
- Event streaming architects
- Platform administrators
Use it when
- Creating a new high-throughput Kafka topic
- Tuning consumers that cannot keep up with production
- Reviewing event stream topologies
A complete run, step by step
Determine target throughput
Identify the total peak bandwidth the topic needs to handle in MB/s.
Measure producer speed
Benchmark the maximum throughput a single producer instance can push.
Measure consumer speed
Benchmark the maximum throughput a single consumer instance can process.
Apply partitioning formula
Calculate the exact partitions required to satisfy the throughput constraints of both producers and consumers.
What you will need
Prepare the following information before starting. Use measured evidence where possible; defaults are examples and should not be treated as recommendations.
Target throughput (MB/s)
The total peak bandwidth the topic needs to process.
Single producer speed (MB/s)
The maximum throughput a single producer instance can push to a partition.
Single consumer speed (MB/s)
The maximum throughput a single consumer instance can read and process from a partition.
What the result tells you
Your report includes
- Minimum required partitions for throughput
- Optimal partition count for parallelism
- Clear constraints for ordering guarantees
How it is determined
The tool applies Confluent's standard partitioning formula: Max(Target / Producer Speed, Target / Consumer Speed). It ensures sufficient parallelism without over-partitioning, which can degrade cluster performance.
The max(target/producer, target/consumer) arithmetic is deterministic, but it is only a throughput lower bound and depends on representative benchmarks.
Model assumptions
- • Per-partition producer and consumer rates were benchmarked on representative hardware and payloads.
- • Keys distribute evenly enough that hot partitions do not dominate throughput.
- • Ordering, consumer concurrency, replication, broker limits, recovery time and growth are assessed separately.
Authoritative references
500 MB/s ingestion stream
Situation
The system must process 500 MB/s. A producer can push 50 MB/s, and a consumer can read 20 MB/s.
Result
The calculation divides 500 by 20, dictating an absolute minimum of 25 partitions to achieve the consumer throughput target.
Use the result with engineering judgement
- It assumes even distribution of keys. Key skew can bottleneck specific partitions.
- It does not calculate replication factor impact on disk I/O.
Questions before you begin
Why not just use 100 partitions for everything?
Over-partitioning increases metadata overhead in ZooKeeper/KRaft and increases end-to-end latency and recovery time during broker failures.
Can I change partitions later?
Yes, but increasing partitions changes the key hashing, breaking strict message ordering for existing keys.
Should I over-provision partitions for future growth?
It is generally better to plan partitions for your 1-2 year target rather than over-provisioning massively, to save on metadata overhead.
Ready to run Partition Calculator?
Open the interactive utility without an account. Inputs and results are not saved.
Open toolGet practical engineering references
A useful digest about twice a week with new error references, tools, integration notes and production lessons. No daily noise.