This message was deleted.
# general
s
This message was deleted.
k
@David K is there any ordering or performance implications for a topic with 1 partition though? Because it seems to me that we could just use 1-partitioned topics, even when global ordering is important, and never increase the number of partitions. Am I misunderstanding something?
d
No there aren’t any performance implications if you always have a single partition. But in that case, what is the point of having it partitioned? To me the main benefit is the ability to increase the partition count in the future, or do you have some other reason?
k
Mostly just looking to simplify our decision process - we may have a topic that has low throughput today, but could scale out in the future. Since migrating from non-partitioned -> partitioned requires deleting and recreating the topic, it seems easier to default to “1-partition” than to default to “non-partitioned” and then migrate to partitioned in the future, unless there are other concerns.
d
Having a standard way that comes with future expansion for effectively free is a good practice as I said before. Just bear in mind the consumption/production part of the equation such as message ordering or message routing across the partitions as you increase the number of partitions.
k
Ok, thanks!
I’m also curious if you know a best practice for whether or not dead-letter-topics for partitioned topics should also be partitioned. It seems like the default behavior is the create one DLQ per partition, but is there a reason not to just use a single DLQ?
d
I am guessing that the assumption is that if there is significant number of messages in the DLQ that you will want them sorted by key across the partitions for faster processing
👍 1