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 > -- Cees de Groot Principal Software Engineer PagerDuty, Inc.
