Kafka Partition Count Calculator

Topic label:

Shown in exported rows only; it does not change the math.

Workload preset:

Start with the closest production topic shape, then replace the rates with benchmarked values.

Sizing basis:

Changing the basis changes which target fields are used for the same partition formula.

Producer capacity per partition:

Replace the default with a benchmark from your producer-perf-test or production metrics.

MB/s

Consumer capacity per partition:

Use application-specific consumer throughput; it is often lower than broker fetch capacity.

MB/s

Peak consumers in one group:

Enter the maximum active instances or threads expected in the busiest consumer group.

consumers

Broker count:

Use the number of brokers eligible to host this topic.

brokers

Replication factor:

Production Kafka topics commonly use 3 when the cluster has enough brokers.

replicas

Keying posture:

Choose the posture that matches producer keys and downstream ordering expectations.

Growth buffer:

Raise this when topic growth is likely or keyed repartitioning would be disruptive.

Buffer slider {{ formatPercent(model.safetyBufferPct, 0) }}

Round partition plan to:

Broker-balanced is the conservative default for topic creation planning.

{{ error }}

Current partitions:

Leave 0 for a new topic.

partitions

Active consumer groups:

Enter groups that read the full topic during peak to estimate aggregate broker read load.

groups

Minimum in-sync replicas:

Common RF 3 topics often use min ISR 2 when producers require committed replicas.

replicas

Leader partitions per broker warning:

Leave 0 when no topic-specific broker guardrail is defined.

leaders/broker

Remaining cluster partition budget:

Use this when platform teams reserve a maximum count for new topic growth.

partitions

Preferred topic maximum:

Use this to flag plans that need broker benchmarks, tiering, or topic redesign before creation.

partitions

Plan item	Value	Sizing detail	Copy
{{ row.item }}	{{ row.value }}	{{ row.detail }}

Footprint check	Value	Broker context	Copy
{{ row.check }}	{{ row.value }}	{{ row.context }}

Buffer	Buffered need	Rounded target	Leaders per broker	Note	Copy
{{ row.buffer }}	{{ row.buffered }}	{{ row.rounded }}	{{ row.leaders }}	{{ row.note }}

Checkpoint	Signal	Action	Operator note	Copy
{{ row.checkpoint }}	{{ row.signal }}	{{ row.action }}	{{ row.note }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A Kafka topic partition is a small decision with long operational memory. It controls how writes spread across brokers, how replicas are placed, how much work one consumer group can split, and where ordering is guaranteed. Once a topic is live, raising the count is possible, but lowering it requires a replacement or migration plan.

The right count depends on measured throughput and consumer behavior, not only on message volume. A stream with modest MB/s can still need many partitions when the consumer application is slow or the busiest group has many active consumers. A high-ingest topic can sometimes use fewer partitions when records batch well, producers compress efficiently, and consumers process each partition quickly.

Kafka partition sizing path from producers through partition leaders and replicas to consumer group parallelism.

Partition: An ordered log inside a topic. Kafka preserves order within one partition, not across the whole topic.
Leader: The broker copy that normally accepts writes for a partition.
Replica: A copy of a partition. The replication factor counts the leader plus follower copies.
Consumer group: A set of consumers sharing work. In the common group model, one partition is assigned to only one active consumer in that group at a time.

Keyed topics deserve extra caution. Records with the same key are routed to the same partition so readers can process that key's records in order. Increasing partitions later can change where future records for a key land, which may be harmless for clickstream data and risky for account, inventory, billing, change-data-capture, or stateful processing topics.

Replication factor is a durability and availability choice, not a parallelism shortcut. Raising it creates more replica partitions and more broker work, while a single consumer group still cannot run more active consumers than the partitions assigned to it. A topic with 24 partitions and replication factor 3 creates 72 total replica placements for the broker set to host and recover.

Good partition planning leaves room for growth without treating partitions as costless. A recommendation should record what forced the number: write throughput, read throughput, consumer count, broker spread, keying risk, or a local platform budget. That record helps later when lag, failover, retention, or cost pressure raises the question again.

How to Use This Tool:

Size one Kafka topic against the busiest consumer group that must keep up with it. Replace defaults with benchmarked producer, broker, and consumer values before using the result in a production change.

Enter a Topic label and choose the closest Workload preset. Use Custom when you want every sizing input to stay under manual control.
Choose Sizing basis. Throughput mode uses direct Target write throughput and Busiest group read target. Event-rate mode derives MB/s from Peak event rate and Average event size, then applies the read target multiplier.
Enter Producer capacity per partition and Consumer capacity per partition from tests that match real acknowledgements, compression, batching, record size, broker class, and application work.
Set Peak consumers in one group, Broker count, Replication factor, Keying posture, Growth buffer, and the rounding rule. Broker-balanced rounding is the default because it spreads leader partitions across the broker set.
Open Advanced when the topic already exists or when platform guardrails matter. Current partitions, active consumer groups, minimum in-sync replicas, leader thresholds, cluster budget, and preferred maximum add warnings and context.
Review Partition Plan, Broker Footprint, Buffer Ladder, Partition Drivers, Capacity Brief, and Topic Command. Fix validation errors before trusting the recommendation.

Interpreting Results:

Recommended partition count is the final whole-partition result after write capacity, read capacity, consumer parallelism, growth buffer, and selected rounding are applied. The largest driver matters because it tells you whether the fix is more partitions, better producer batching, faster consumers, a different key design, or a cluster-capacity review.

Kafka partition count result interpretation
Result area	What to read first	What not to overread
Partition Plan	Recommended count, base requirement, write floor, read floor, consumer floor, buffer, and keying caution.	A rounded count can be higher than the raw need because broker or consumer divisibility was requested.
Broker Footprint	Leaders per broker, replicas per broker, total replicas, per-partition rates, and broker traffic estimates.	Replication improves redundancy only when brokers and in-sync replicas can sustain the write path.
Buffer Ladder	How alternative growth buffers change the rounded partition target.	A small buffer increase can jump to a much larger count when rounding multiples are awkward.
Partition Drivers	Which floor or rounding step pushed the recommendation upward.	A high chart bar is not always a broker problem; it may be the consumer group floor.
Capacity Brief	Warnings about keying, current partition delta, leader density, replica density, budgets, and benchmark readiness.	Warnings are review gates. They do not automatically prove the count is wrong.

A count that clears the math can still be the wrong operational change. Verify the largest driver, check keyed-topic migration risk, compare leaders and replicas with broker limits, and confirm the generated command against your change process before applying it.

Technical Details:

The model computes three partition floors: producer write throughput, busiest-group read throughput, and planned consumer parallelism. It takes the largest floor, adds growth headroom, and rounds upward according to the selected rule. Whole-partition ceilings are used throughout because 5.01 partitions still means 6 partitions before buffer and rounding.

Throughput mode uses the write and read MB/s values directly. Event-rate mode converts events per second and average event size in KiB into write MB/s, then multiplies that value for the busiest-group read target. The event-rate fields remain visible in throughput mode for context, but they do not drive the direct-throughput calculation.

Formula Core:

The formulas below show how the unrounded need is built before the selected rounding rule is applied.

\begin{array}{lcl} W_{event} & = & \frac{E \times S}{1024} \\ P_{write} & = & ⌈ \frac{W}{C_{producer}} ⌉ \\ P_{read} & = & ⌈ \frac{R}{C_{consumer}} ⌉ \\ P_{base} & = & max (P_{write}, P_{read}, N) \\ P_{buffered} & = & ⌈ P_{base} \times (1 + \frac{B}{100}) ⌉ \end{array}

Kafka partition formula variables
Symbol	Meaning	Boundary or unit
`E`	Peak event rate.	Events per second, zero or greater.
`S`	Average event size.	KiB per event, zero or greater.
`W`	Target write throughput.	MB/s, must be greater than 0.
`R`	Busiest-group read target.	MB/s, must be greater than 0.
`C`_producer	Measured producer capacity per partition.	MB/s per partition, must be greater than 0.
`C`_consumer	Measured application consumer capacity per partition.	MB/s per partition, must be greater than 0.
`N`	Peak consumers in one group.	Whole number, at least 1.
`B`	Growth buffer.	0% to 500%.

Kafka partition rounding and warning rules
Rule or guardrail	Boundary	Operational meaning
No rounding	Use the buffered ceiling directly.	Smallest whole count after growth headroom.
Broker multiple	Round up to a multiple of broker count.	Helps leader partitions divide across brokers.
Consumer multiple	Round up to a multiple of peak consumers.	Helps a full consumer group divide assignments more evenly.
Broker and consumer LCM	Round up to the least common multiple of brokers and peak consumers.	Satisfies both multiples, but warns if the multiple is more than four times the base requirement.
Next power of two	Round up to 1, 2, 4, 8, 16, and so on.	Can provide sharding headroom, but may not align with brokers or consumers.
Large topic warning	Recommended count greater than 1,000 or leaders per broker greater than 200.	Review controller, metadata, file handles, failover, and rebalance behavior.
Replica density warning	Replica partitions per broker greater than 4,000.	Validate broker metadata, monitoring, recovery, and rolling-update behavior.

Broker footprint estimates are derived from the rounded recommendation. Total replicas equal recommended partitions multiplied by replication factor. Leaders per broker divide recommended partitions by broker count, while replicas per broker divide total replicas by broker count. Per-broker disk write is modeled as write MB/s times replication factor divided by broker count, and follower replication traffic uses write MB/s times replication-factor minus one divided by broker count.

With the default balanced production inputs, write throughput requires ceil(60 / 12) = 5 partitions and read throughput requires ceil(60 / 18) = 4. The 12 planned consumers set the base requirement at 12. A 25% buffer raises that to 15, and broker-count rounding across 6 brokers returns 18 partitions.

Worked Examples:

Balanced production topic

A topic targeting 60 MB/s writes and 60 MB/s reads for the busiest group has measured capacities of 12 MB/s per producer partition and 18 MB/s per consumer partition. The write floor is 5, the read floor is 4, and the planned 12-consumer group sets the base. With 25% buffer and broker rounding across 6 brokers, the recommendation becomes 18 partitions.

Event-rate planning

A stream at 8,000 events per second with 3 KiB average events produces about 23.44 MB/s before any read multiplier. If consumer capacity is 12 MB/s per partition, read throughput alone needs 2 partitions, but the final count may still be higher because the consumer floor, buffer, and broker rounding are separate requirements.

Existing keyed topic

An ordering-sensitive topic with 12 current partitions and a modeled need of 18 should be treated as a migration review. The current partition delta tells you the increase, while the keyed-workload warning points to replay tests, state-store behavior, and downstream ordering assumptions before an alter command is used.

Validation before reading the result

If replication factor is greater than broker count, the calculator reports that normal topic placement is impossible. Reduce the replication factor or size against a larger broker set. If minimum in-sync replicas is greater than replication factor, adjust one of those values before using the recommendation.

FAQ:

Should read traffic from every consumer group be added together?

Not for the partition formula. Use the busiest single consumer group to size parallelism, then use active consumer groups to interpret aggregate broker read egress.

Why can the recommendation exceed the base formula result?

Growth buffer and upward rounding are applied after the write, read, and consumer floors. Broker multiple, consumer multiple, least common multiple, or power-of-two rounding can all raise the final count.

Can a Kafka topic partition count be decreased later?

Kafka can increase partitions for an existing topic, but it cannot shrink a topic in place. A lower target requires creating or migrating to another topic.

Does replication factor make one consumer group faster?

No. Replication factor creates additional copies for durability and availability. Consumer parallelism in a traditional group is still limited by partition assignment.

Why is a keyed-topic increase warned about?

Changing the partition count can change future key-to-partition placement. If processors depend on per-key order, test the migration before altering the topic.

Glossary:

Base requirement: The largest unbuffered count among write throughput, read throughput, and peak consumers.
Buffered partitions: The base requirement after the growth buffer is applied and rounded up to a whole partition.
ISR: In-sync replicas, the replicas caught up enough to count for committed writes under the topic's durability settings.
Leader partitions per broker: The recommended partition count divided by broker count.
Replica partitions per broker: Total leader and follower replicas divided by broker count.
Current partition delta: The difference between current partitions and the modeled recommendation.

References:

Apache Kafka documentation, Apache Software Foundation.
Choose and Change the Partition Count in Kafka, Confluent Documentation.
How to configure Filebeat output to Kafka, Simplified Guide.
How to configure Logstash output to Kafka, Simplified Guide.

Kafka Partition Count Calculator

Introduction:

How to Use This Tool:

Interpreting Results:

Technical Details:

Formula Core:

Worked Examples:

Balanced production topic

Event-rate planning

Existing keyed topic

Validation before reading the result

FAQ:

Glossary:

References: