Question

I own an application that uses Neo4j as graph database.
I separated read and write (following CQRS advices) in order to implement the command pattern and optimize my requests (page requests), the whole sharing a same database: the neo4j database. (not two distinct)

Now I'm planning to store some domain events like UserRegisteredEvent etc. in order to be dequeued by some event handlers hosted in Actors (Akka).

Does it make sense to store the domain events in the shared database, in my case as simple Neo4j nodes?
Or should I really need a tierce database, like MySQL for instance?

I precise that I don't need Event Sourcing with my solution.

Was it helpful?

Solution

If you can relate the stored events in some way or you want to add further information to these events that can be represented with relationships or just properties, a graph database (in your case neo4j) is the way to go since queries will be much faster than a (or not so) normalized rdbms.

Also in the future you can easily add more properties without taking care of the SQL and the missing properties for entities already added.

So from my point of view, adding events nodes to the shared neo4j database is a better approach, even for simple nodes, since queries are made into sub-graphs and it will not influence your business domain.

OTHER TIPS

I don't no much about Neo4j but theres no rule that says you have to use a RDBMS as an event store - as long as you can write and read a set of events (as objects serialized/deserialized) in sequenece based on an aggregate id then your good.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top