0

Contrived example, but say I have an Order aggregate with OrderLine entities. The order line contains cost, quantity and the name of the product. The aggregate is persisted as events to be event sourced. Typically, a single product could have millions of orders.

I now have to update the name of the product. Updating the product aggregate is simple enough but I now have millions of orders with the old product name.

This is a contrived example but assume I need to update this copied state in my orders. What’s the best approach here? Applying the state change to such a huge volume of records seems incredibly expensive operation.

Sio
  • 1,419
  • 1
  • 13
  • 23
  • 1
    Why would you copy the information (product name) if you wanted to reference the source data? Also, if there's no transactional contention then batch processing may look more effective, but how many concurrency failures could you face trying to update 1M orders in batch? Should the whole transaction fail if just one fails in the whole batch? Not sure what's the best approach here, but the `ProductRenamed` event would probably kick-off some kind of long-running process that updates orders over time until everything is consistent. – plalx May 24 '21 at 00:09
  • The update can be eventually consistent. Should have clarified that. The primary reason for copying the data is product name is typically always rendered along with the product line. I think this is fine for data that’s immutable but perhaps I should be looking at a view model from multiple aggregates. – Sio May 24 '21 at 06:49

1 Answers1

0

In general, when event sourcing, events are immutable: they represent things that have definitively happened and you can't change the past. If somebody ordered a product "Foo", what is the benefit of later saying they ordered "Bar"?

There's a minor exception around schema migration, which would likely be an offline process manipulating the event store, after ensuring that anything reading the events can use either the old or the new encoding. This doesn't change the semantic meaning of the events.

If you really needed to correct every aggregate, new events can be recorded (e.g. removing the old product from an order and adding the new product). This would tend to be done order by order: remember that aggregates tend to define consistency boundaries, so this would be eventually consistent (you could perform arbitrarily many aggregate updates in parallel: event sourced systems tend to be trivially massively parallelizable for that sort of thing).

Levi Ramsey
  • 18,884
  • 1
  • 16
  • 30