Microservice arcitecture - seperation of services

Question

The Microservice arcitecture is still a new thing for me to work with, so it gives me some unanswered questions.

In my case each MicroService has its own database.

I need a UserService to handle CRUD operation for users. Lets say we have a User table with the columns Id, Name, UserTypeId and a UserType table with the columns Id, Name, Code (unique code to identify the specific user type).

My question is now should the UserService handle the UserType table too or should that be seperated into a new MicroService and then copy the new UserTypes into the UserService by message events?

Now lets say we also want to manage some access permissions for the users. We want a Permission table to hold all the permissions the system contains. My thoughts is to create a PermisionService to handle the permissions CRUD operations and eventually other features regarding permissions.

It should be possible to attach a permission to a user by using a table like UserPermissions (UserId, PermissionId)

Now my question is should I create a new service for handling the attachment and removal of permissions on users or should the UserService also clone all permissions by message events and then handle it in the UserService by having a AttachPermissionsToUser endpoint?

What do you think is the proper implementation?

Answer 1

Microservices are a tool for organising development teams and the independent maintenance of features. Splitting a database into one microservice per table will ruin performance for no measurable gain.

You need to ask the question of your teams as to where the microservice boundaries need to be.

If you are a solo developer, you almost never need microservices.

Answer 2

I do not think there is a simple answer on how to divide code into services. Is a fundamental problem in microservices, and not just microservices. It is generally difficult to know how to divide code into modules.

If there is some kind of security consideration that might be a reason to split these parts into a separate service. That way you can have more stringent security procedures for the sensitive parts, and more relaxed policies for other components.

I would tend to error on the side of placing things into the same service. The effect of to large service should be more a larger and more difficult code base, and increased overhead for things like coordinating releases. The effect of to many services would be larger overhead to get anything done, since new features are more likely to require changes to many services, and each change needs to be done without affecting backward compatibility etc. There might also be potentially serious performance problems since simple method calls may turn into costly network calls.

Because of this I have heard it claimed that microservices are most successful when you have already built a monolith of your application, that way you hopefully have a decent idea of what parts are tightly coupled, and what parts can be split into different services.

Answer 3

For microservices architecture I believe it will be easier if you start by specifying your business domain and then the related bounded contexts. After you have an agreement on that between IT and business people it will be clear what and where you should creat microservices. If you start from microservices first then mostly you will miss the broad picture and will end up cloning the same legacy monolith that you are trying to redesign.

Answer 4

My rule of thumb is to create fat services until they can not be scaled anymore. If I were you I would separate everything by domain and not by technical domain. Everything user related goes into one service. This service has its own database and does not share it with others. When you start seeing that you use one endpoint 90% of the time, you can extract that endpoint to a service. This way you dont optimize pre-maturely.

Thinking ahead of the time is good but dont fall into "analysis paralysis" trap.