Partition count can only increase, never decrease. This is a design constraint of Apache Kafka, not specific to ApsaraMQ for Kafka.
How partition assignment works
Kafka assigns each message to a partition based on hash(key) % number_of_partitions. Each partition stores an independent, ordered log of messages. Removing a partition causes two problems:
Data loss. All messages stored in that partition are lost.
Key redistribution. The modulus changes, so the hash mapping shifts for every key. Consumers that rely on key-based ordering -- for example, processing all events for a single user in sequence -- receive messages out of order or lose them entirely.
What to do instead
Plan partition count upfront. Estimate based on target throughput and consumer parallelism, then round up. Adding partitions later is possible but still shuffles key assignments, so over-provision from the start.
Recreate the topic if you need fewer partitions. Create a new topic with the desired partition count, migrate producers and consumers to the new topic, then decommission the old one after all messages have been consumed or expired.
High availability (HA) limitations of single-partition topics
In cloud storage mode, a topic with a single partition (partitionNum=1) does not provide high availability (HA). If the node hosting that partition becomes unavailable — whether due to a node failure or an upgrade — the topic is inaccessible until the node comes back online.
The Message Queue for Apache Kafka console warns you when you attempt to create a cloud storage topic with a single partition. Single-partition cloud storage topics are not recommended.
How retries behave with single-partition topics
The Kafka producer retry mechanism affects single-partition topics as follows:
During rolling upgrades — When a node temporarily goes offline during a planned upgrade, the retry mechanism can reduce the impact of the interruption. Producers can retry message delivery and resume sending once the node recovers. This reduces (but does not eliminate) message loss during planned maintenance.
During unplanned node failures — Retries cannot prevent data loss when a node fails unexpectedly. If the node does not recover within the retry window, messages in the retry queue may still be lost. Retry policies cannot substitute for HA.
To ensure high availability for production workloads, configure your topic with at least two partitions. With multiple partitions, Message Queue for Apache Kafka continues to serve read and write requests from replica partitions on healthy nodes even if one node fails.
What are the risks of modifying the partition count of a Kafka internal topic?
Kafka uses internal topics (such as __consumer_offsets) for internal bookkeeping and state management. Although Kafka clients can typically detect partition count changes automatically, manually changing the partition count of an internal topic (for example, increasing it from 1 to 12) introduces significant risks:
Message ordering issues — Changing the partition count alters how messages are routed to partitions. Messages that were previously assigned to one partition may now map to a different partition, causing messages to be processed out of order.
State inconsistency — Internal topics store critical state data such as consumer group offsets. Modifying their partition count can corrupt this state, leading to unexpected consumer behavior, rebalancing failures, or cluster instability.
Do not manually modify the partition count of internal topics. If you believe a change is necessary, contact Alibaba Cloud technical support to evaluate the risks before proceeding.