Head's Up! These forums are read-only. All users and content have migrated. Please join us at community.neo4j.com.
04-03-2019 12:24 AM
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.
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?
Solved! Go to Solution.
04-03-2019 09:54 AM
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.
04-03-2019 09:54 AM
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.
08-31-2022 04:14 AM
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.
04-03-2019 10:20 AM
@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?
04-03-2019 10:45 AM
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.
All the sessions of the conference are now available online