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.