cancel
Showing results for 
Search instead for 
Did you mean: 

Head's Up! These forums are read-only. All users and content have migrated. Please join us at community.neo4j.com.

Neo4j Database Modeling with respect to microservice architecture

If we are using microservice architecture with one neo4j instance per microservice, how does neo4j benefits this architecture with respect to other microservices? And how should one break the neo4j models into different microservices?

Assume we have to build a twitter clone referencing this awesome post by MAX DE MARZI. Following is the database model we would have if it would be a monolithic app.

2X_8_8caae04969b4553cbe02cd11067bf19e46cdb646.png

Suppose if we have 2 microservice named as M1 - which is for User management in all the informations regarding a particular user is stored and then we have a M2 microservice in which all the tweets, chats, retweets, etc. are stored. How should we model the database to support this architecture?

1 ACCEPTED SOLUTION

I need to take issue with the premise of the question a little bit. To have microservices is about decomposing the services themselves, but why do you assume that you would want a single neo4j instance per micro-service? There's certainly nothing wrong with having multiple microservices access the same database.

Suppose you didn't. Well, in order to correlate data between the microservices (for example M1 would be in charge of the canonical ID for a user, while the M2 would handle the tweet ID) -- you would end up with some problems of getting them to agree or possibly be out of sync with one another. Also, one of those two neo4j instances needs to store the correspondance from (:User)-[:POSTED]->(:Tweet). Let's say you did that in M2. Because M2 isn't the canonical source for users, it'd end up with a shell :User node with just an ID, which could possibly be wrong and out of sync with M1's user.

I don't think these troubles are worth it. The better architecture would be to have a single Neo4j instance serving multiple microservices, using the data model you already posted.

View solution in original post

4 REPLIES 4

I need to take issue with the premise of the question a little bit. To have microservices is about decomposing the services themselves, but why do you assume that you would want a single neo4j instance per micro-service? There's certainly nothing wrong with having multiple microservices access the same database.

Suppose you didn't. Well, in order to correlate data between the microservices (for example M1 would be in charge of the canonical ID for a user, while the M2 would handle the tweet ID) -- you would end up with some problems of getting them to agree or possibly be out of sync with one another. Also, one of those two neo4j instances needs to store the correspondance from (:User)-[:POSTED]->(:Tweet). Let's say you did that in M2. Because M2 isn't the canonical source for users, it'd end up with a shell :User node with just an ID, which could possibly be wrong and out of sync with M1's user.

I don't think these troubles are worth it. The better architecture would be to have a single Neo4j instance serving multiple microservices, using the data model you already posted.

Hi David, 

rescuing this reply to see the state of Neo4j in relation to microservices architecture nowadays. In our project we started with a monolithic approach and now we are considering moving to a microservices architecture. 
Also, I don't see much content on this topic (Microservices + 1 (or more) Neo4j instances)

Thank you.

@david.allen Hey, I think you're right.
Although there's one more question, suppose if I have hosted my neo4j instance on DigitalOcean's virtual server and build a good amount of user base there and then want to switch to my own dedicated cloud infrastructure then how will I move all my data from that server to my own?

Many, many options to move your data.

If you have a causal cluster, you can add new core nodes to your cluster in the new place, allow it to replicate transactions, then eventually shut down the machines that were in the original place.

If you don't have a causal cluster you can just take a backup and then start a new database in the new place with the backup.

What to do depends on requirements like whether you need it to be un-interrupted, how much data we're talking about, what the write workload is like, and so on.