Microservices - Should each service have a notion of a user

Question

Should each Microservice have a user account account created for each user that will have resources created for them on the Microservices?

For example if there is a user profile service, should there be an endpoint for creating a user then creating a profile, or should you create a profile with a user id.

The purpose of creating a user first is for each user it acts as a starting point for locating all their resources on a microservice?

The disadvantage is when a user joins a system, for each micorservice you would have to create user for them on each microservice.

Answer 1

It sounds like you are thinking of micro-services as separate applications, which a user interacts with directly. While some might work that way, a better mental model is that each micro-service is a component within a single application, and the user is interacting with the application as a whole.

Each micro-service has its own set of entities or resources that it is responsible for, and which are relevant for its purpose or domain.

Take for instance a micro-service responsible for managing product stock in the warehouse of an e-commerce company. The end-user of the application might be a user searching for products, but they don't own any resources in the warehouse, so there is no need for them to be persisted anywhere in the warehouse micro-service. The permissions model of the warehouse service only needs a fixed role which grants all customers the same read-only access to the stock levels.

The example of a "user profile service" is different. This service has a responsibility which involves modelling users, and making information about them available to the rest of the system. It definitely needs a persistent "user" entity. It's slightly unclear to me what a "profile" would be as an entity, but you might first create a "user" entity, and then add a "delivery address" entity, a "login credentials" entity, and so on.

Other services might reference users, but not manage them. For instance, an "order history" service would need to record which orders belonged to which users, but those users would simply be references to the entities already created in the user profile service. There wouldn't, for instance, be a "Users" table in a database used solely for the order history service. There might be some other entity which had exactly one instance (e.g. one database row) for each user, but that wouldn't be a "user" entity, it would be something specific to the domain of "order history".

Answer 2

No. At least not in the sense that you have to actually create the user first on the service.

There are all sorts of options you could do.

Have one service issue JWTs, and others accept that user to exist when the token is presented to them.

Have no users at all, but have the tokens include what resources they can access. (If the resources are limited, grouped, or similar)

Have the service return some cryptographically secure id to the client with which it can use to refer to its own resources at a later time. Without explicitly creating a "user" as such.

Have some more complicated "federated identity", "SSO", or similar from somewhere else, where you can also carry resource rights information.

And so on..