Thanks. Apparently there is nothing wrong with that :-)
I came to the same conclusion in an earlier post.
Would be good if someone having experience with Kafka and event sourcing
corrected this stackoverflow answer (i.e. update 2):
http://stackoverflow.com/questions/17708489/using-kafka-as-a-cqrs-eventstore-good-idea/17813930#17813930
On 30/03/16 05:32, Cees de Groot wrote:
What's wrong with multiple aggregates per partition? You'll still process
all events for each aggregate in order. If you want to just replay for a
single aggregate somewhere, Kafka can spit out events fast enough to allow
you to quickly skip through all the stuff you don't need...
On Mon, Mar 28, 2016 at 10:53 AM, Mark van Leeuwen <m...@vl.id.au> wrote:
Hi all,
When using Kafka for event sourcing in a CQRS style app, what approach do
you recommend for mapping DDD aggregates to topic partitions?
Assigning a partition to each aggregate seems at first to be the right
approach: events can be replayed in correct order for each aggregate and
there is no mixing of events for different aggregates.
But this page
http://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster
has the recommendation to " limit the number of partitions per broker to
two to four thousand and the total number of partitions in the cluster to
low tens of thousand".
One partition per aggregate will far exceed that number.
Thanks,
Mark
