10

My Order aggregate root is able to emit several Event, e.g. OrderCreated, OrderPaid, OrderCancelled. Would it be good design to store all types of order event into single kafka topic and to have the orderId as the message key, as suggested here? Or Should I create sepparate topic for each of them?

The pro of having single topic is that the order of events is maintained, but consumer would need to filter some events on their end. The pro of second approach is consumer would be simpler as they can subscribe to the exact topic that they need, but constructing Order requires subscribing to multiple topic while they don't come from kafka in the right sequence as they are from different topics.

Thank you

Community
  • 1
  • 1
Fajarmf
  • 2,143
  • 4
  • 19
  • 23
  • I am in the same boat. I will probably go with grouping aggregate events under single topic as you would do with storing events and replaying later, you probably want to deal with single "collection" where you have all necessary events around aggregates. Probably permissions, redundancy requirements are same around single aggregate. – Aram Sep 14 '16 at 07:22
  • What did you decide? I'm also in this boat. – Josh C. Oct 15 '17 at 13:05
  • 1
    I ended up with single topic in most cases ( transactional logs) as I found the benefit of having events sorted outweigh the cost of filtering unused one. – Fajarmf Oct 15 '17 at 23:09

1 Answers1

3

I am not sure if there is a right/wrong question, however here are my two pennies' worth of it:

  • My rule-of-thumb is a topic for each bounded context to strike a balance between ease of management and amount of events received by the listeners
  • Events need to be sequenced anyway, so that they are stored in the EventStore in the right sequence. Add a sequenceId to your event and use a Resequencer (e.g. in Camel) to make sure that a listener processes events in the right order.

Hope that helps and good look with your project.

Alessandro Santini
  • 1,943
  • 13
  • 17