It seems like you're trying to use the partitioning mechanism as a routing
mechanism, which afaik is not really its objective.
It may work but it is definitely not the best approach imo.
1. You're throwing away the parallelism capabilities of Kafka. You'll have
a single "queue" per customer. By th
That might be ok. If that's the case, you can probably just "precreate" all
the partitions for them upfront and avoid any worry about having to futz
with consumers.
On Tue, May 23, 2017 at 4:33 PM, David Espinosa wrote:
> Thanks for the answer Tom,
> Indeed I will not have more than 10 or 20 cus
Thanks for the answer Tom,
Indeed I will not have more than 10 or 20 customer per cluster, so that's
also the maximum number of partitions possible per topic.
Still a bad idea?
2017-05-23 16:48 GMT+02:00 Tom Crayford :
> Hi there,
>
> I don't know about the consumer, but I'd *strongly* recommend
Hi there,
I don't know about the consumer, but I'd *strongly* recommend not designing
your application around this. Kafka has severe and notable stability
concerns with large numbers of partitions, and requiring "one partition per
customer" is going to be limiting, unless you only ever expect to h
Hi there,
I don't know about the consumer, but I'd *strongly* recommend not designing
your application around this. Kafka has severe and notable stability
concerns with large numbers of partitions, and requiring "one partition per
customer" is going to be limiting, unless you only ever expect to h
