0

I am having a task of building a new service (a.k.a microservice) for a user settings service.

The purpose of this service is to store settings of users in the system. Settings mostly come in the form of key-value pair with user_id.

Some feature requirements for this service:

  • The service should be designed so that it's scalable for read.
  • The service should be designed such that it's easily plugable and extensible. Let's say in the future we want to introduce more types of user setting in the system, it will be easily doable with minimal additional effort.

Currently I am at the stage of database design and modelling for this service, and have some questions which I want to ask:

  • Is there any good practice/principles/examples out there in the industry about this type of service in particular?
  • Will relational (SQL) or non-relational (NoSQL) database will fit more for this case? I have already read about this relational design, I am wondering whether NoSQL will fit this use case, because most of the time we are storing key-value pair for the setting.
  • Is there another alternative design that I can consider?
  • Assume that NoSQL will fit to solve this problem, which NoSQL database should I choose? I don't have experience with NoSQL and there are many databases out there in the market to pick.
Pham Vu Tuan
  • 1
  • 3

1 Answers1

0

Your question is a bit too broad and vague in general, but I will try to address it based on the information you have provided and given that you mentioned that this is a micro service :

  • First of all, are there other micro services in use at the company or others planned? I assume there has to be since building a single micro service would not make sense. As such I would check to see what the other services are using and pick a technology that is compatible (or even the same unless for some reason it is really bad)

  • For what your are describing, most DBs will do just fine. Storing user settings is not a particularly intensive task and is probably not going to generate billion of records. As such, see what else the company is already using first and check if you can use the same thing (unless they are using something ancient, in which case see if there are other projects that ar planning to use a different DB)

  • NoSQL vs SQL; For a micro service as yours, it really will not make a difference. As such pick whatever you are comfortable with. For relational I would suggest MariaDB or Postgres and for NoSQL maybe MongoDB or ArangoDB. But those are personal preferences. Everybody on the web will suggest something different.

  • Should you consider an alternative design? Well micro services are all the rage today so it is understandable that you picked that. I think it is a great architecture, but you should know that as the number of micro services increases there is a price to pay for its flexibility and maintainability and that is about traceability. As long as you are well informed about its advantages and disadvantages , there is no real reason not to use it. I would recommend you read Microservices in Action to get a great introduction.

camba1
  • 1,795
  • 2
  • 12
  • 18
  • Thanks a lot! I want to address one of your concerns: - The current setup is we have different services will handle different user settings, so the data is fragmented in multiple places. The purpose of this new service is to aggregate all of these data into one place, it's more maintainable and tracable if we can have a single source of truth. – Pham Vu Tuan Jul 16 '19 at 15:44