4

Let's say we have design our system using akka-persistence. Now, we have events stored in the event-store. While, the system in production, a new feature was requested. As a result, we find the best way to go about it is to add or modify a field in an event. Let's say by changing the field name or type.

Now, we have two versions of the event, the one we have in production, and the one in the new deployment, which are not compatible. We will fail if we try to recover data from the old version.

What is the best way to go about that, other than data migration?

Muhammad Farag
  • 426
  • 2
  • 12

1 Answers1

5

This is definitely one of the bigger issues with using akka persistence in production. There has been a lot of discussion about this on the akka-user mailing list.

I would say that as long as the new feature requires just additional information, going with a serialization format that allows limited schema evolution such as google protocol buffers or json would be a solution.

If the new feature requires changing the existing data, there is nothing you can do but to do data migration.

Rüdiger Klaehn
  • 12,445
  • 3
  • 41
  • 57
  • Thank you Rüdiger, we actually went with protocol buffers, but it is sort of "unclean" and messy! I hoped there would be a cleaner version... Also, my understanding that using json will result in a hit in performance... – Muhammad Farag Jul 22 '15 at 12:49
  • protobuf will be faster and more compact than JSON. For the fundamental problem of schema migration I don't really see a good solution. Either version your events and have code that reads each old version and writes in the latest version (yuck!) or add optional data protobuf style and hope that you have covered all possible combinations of options. – Rüdiger Klaehn Jul 22 '15 at 15:59