0

I am currently developing a .NET Core application based on a microservices architecture. As part of this, we are designing an Identity microservice for user authentication and authorization.

We're considering a polyglot persistence approach, specifically using SQL Server for user profile data, given its strong support for structured data and ACID transactions, and Neo4j for managing complex relationships and access control lists, given its ability to handle complex relationships and queries efficiently.

However, we're aware that this approach introduces architectural complexity, as the application would need to interact with two different types of databases and manage data consistency across them.

Do you have any real-world experience or examples of systems that use both SQL Server and Neo4j for an Identity microservice? What are the key considerations we should take into account in terms of architecture, performance, data consistency, and operational complexity?

Any advice, lessons learned, or pointers to relevant resources would be greatly appreciated.

2 Answers2

0

If the reason for you to add SQL Server to your solution is only (or mainly) ACID transactions, I'd recommend to ditch it and stick with Neo4j as it is ACID compliant and you would have the best of both worlds (node properties for your respective SQL columns and relationships from a Graph DB), without the complexity you mentioned. Consistency is hard enough with same DBMS and data types. If you add other types in the mix, it can get really hard to manage and scale.

0

Absolutely, combining SQL Server and Neo4j for an Identity microservice within a microservices architecture can provide the best of both worlds - structured data management and efficient complex relationship handling.

To navigate this approach successfully, start by clearly defining the scope of data for each database - utilize SQL Server for storing user profiles and sensitive information, while Neo4j can be leveraged for managing intricate relationships and access control lists.