What is the best way to organize a microservice architecture?

Question

Service Oriented Architecture

I understand microservices, I read that a separate microservice is needed for each entity.
For example, I have a microservice of clients. The client has a field that describes its gender (GenderId). In EF core, this is a one-to-many relationship. Do I need to move the gender entity to a separate microservice, if not, do I need to make a GET method in the client microservice to get the list of gender?

Answer 1

No, separating genders into a microservice is a bad idea. And the allocation of each entity to a microservice is a very problematic delusion, because there may be a strong connection between them - one entity without the other may turn out to be almost useless, and the load will begin to go off scale.
From an architectural point of view, the external purpose of services, incl. microservices is replaceability, scalability and maintenance of the system in parts. The rest of the architectural concept and methodology is built around these principles.
But there are simply no equivalent concepts at the internal level (algorithmic or logical). There are some recommendations that can simplify or narrow the problem, but in the final form it is modeling and analysis of options (roughly speaking - overkill)

Answer 2

You are trying to divide the monolith functionally, but you need to divide it according to the business logic of the application. The Users microservice works by itself and the gender table is included in its database. How many requests to the database the service will make is already an architectural feature of your microservice. The main idea of ​​microservices is isolation, autonomy, scalability. Based on this, build.