The programming with languages and development frameworks, this type of database is not good enough to cover all the uses of application scenarios.
To choose to use a database is necessary to assess the functioning and microservice operation mode in question. There are situations where the relational database makes sense, at other times one NoSQL can be better, and there are, of course, situations where none of these databases are sufficient and we need to use the database using graphs. This is exactly the situation in our news portal.
It would be very simple to say that SQL is sufficient for all, but it definitely is not. Think of our microservices to see what kind of database is best for each. The following application has these areas:
- SportNewsService
- PoliticsNewsService
- FamousNewsService
- RecommendationService
- UsersService
For microservices that directly show news, if you think about it, there is a direct relationship system. The purpose of these microservices is to simply and quickly bring out the news theme by batch. This behavior is very close to NoSQL, where the relational structure is weak and the speed of basic operations such as searches are faster.
For services and the features previously mentioned, use one database NoSQL, which in this case will be the MongoDB. This choice includes good documentation, and performance benchmarks of implementation simplicity and cost.
UsersService is totally different. A user's credentials for an application is only a login and a password, but there is other data that is related to this login and password. This will be the case for any possible registration data or default preference. So, we have information-relevant relationships in this area, but the best option is to use a conventional SQL.
The UsersService can use a database such as MariaDB, MySQL, Oracle, SQL Server, or PostgreSQL, for example. In the case of our application, use PostgreSQL due to compatibility features, maturity, and compatibility with the rest of the stack already selected.
There is another microservice with an entirely different function from the previous microservices. The RecommendationService should establish the relationship between preferences and users, but not only that. You should also be able to provide what or how many users are interested in the same topic. You can create this type of relationship with a conventional SQL database. However, over time, increasingly complex queries will emerge, and possibly a microservices understanding of speed, as well as maintenance, can be compromised by a bad choice in the stack of conception.
For RecommendationService, a good option is to adopt the database Neo4J. The quality of work with graphs and simplicity of the tool is exactly what we are looking for in this microservice.
The big target when it comes to the database, is again, understanding how the fields behave and not putting in any comfort zones at the time of choice. The most important thing is always to choose the best tool for each case.