CODEWITHSUNDEEP
node.jsneo4jmulti-tenantgraph-databasesarangodb
zulqarnain
zulqarnain

Reputation: 1626

Multi-tenancy Architecture in a graph DB

I would like to share my thoughts with you and try to get some advice. I would like to define my application with the best architecture as possible. Any comment would be highly appreciated. Here we go...

My technologies: NestJs(Node), neo4j/arangodb(graph DB), Nginx for proxy(Micro-services Approach).

My business case: SaaS application. Many customers with many users, one database per customer and the same code (just one instance) of our codebase.
we have a set of data models which will be same for all customer but a relation between them will differ. As per my research GraphDB is the best match for such operations. so I'm planning to create separate Instance/Database for each customer otherwise too many relations will make harder to scale.

Problem: From my point of view the problem can be seen with two different approach.

  1. I need to allow multiple users to connect to different databases at the same time with the same code (just one installation). In Nestjs App how can I change the database configuration on each API request. Shall I save DB URI in a table, based on user/customer type it will fetch DB URI? then other concerns like does it affect on latency time, if any request failed then is there any possibility that request can fetch data from wrong DB?
  2. How can we create sub-graphs in neo4j/arangodb so we can fetch sub-graph based on the customer.

On the other hand, I found a couple of interesting links:
https://neo4j.com/developer/multi-tenancy-worked-example/
https://www.arangodb.com/enterprise-server/oneshard/
https://dzone.com/articles/multitenant-graph-applications

Someone could provide me aditional info?

Thanks for your time

Best regards

Upvotes: 2

Views: 1257

Answers (1)

David Thomas
David Thomas

Reputation: 2349

With ArangoDB, a solution that works is:

  • Use a single database for all customers
  • Use Foxx microservices in that database to provide access to all data
  • Enforce a tenantId value on every call to Foxx
  • Use dedicated collections for each tenant in that database
  • Set up a web server (e.g. Node.js) in front of ArangoDB that serves data to all tenants
  • Only allow connections to Foxx from that front end web server

Each tenant will need a few collections, depending on your solution, try to keep that number as low as possible.

This model works pretty well, and you're able to migrate customers between instances / regions as their data is portable, because it's in collections.

Upvotes: 1

Related Questions