Microservices architecture: Divide micro services by user roles alone

Question

I have encountered the following design requirement in an app marketplace like project from a client in which users can rate games/apps they download (only in a special way more helpful than traditional marketplaces).

My question is regarding microservices architecture, If I have a game user, app owner, market place moderator and market place admin roles and they have common API's they are using but also different ones where in some cases, for example, user can review an app but only moderator and admin can edit that review, so basically I can approach the design by having a microservice that is responsible for app reviews and have a single method SaveOrUpdateAppReview and then based on authentication and authorization both user, moderator and admin could call this method but update will only work for moderator and admin or I can perhaps split it into microservices based on roles, so ill have AppReview microservice having only createReview method and AppReviewModeration microservice in which will have both createReview (as moderator can also create a review) and editReview).

This example repeats itself in many workflows and use-cases, e.g 2, the app owner cannot change app price under certain conditions but admin can, so perhaps the method that enables it to do it should only be under App Admin microservice?

To sum it up, if different roles have different APIs they require, should I handle it in the design level, splitting/dividing it into different microservices or is it part of an internal authorization claim based logic and each method should check if its create or update and enable/disable accordingly.

Regards,

James

Answer 1

Don't couple architecture to authorization policy. It's normal and expected to have code blocks branching on the user's permissions. Depending on how complex it is, you can keep it out of the way of other business logic by putting it in decorators / middleware.

If you have several frontends (e.g. game user and app owner are different apps), it can make sense to have a dedicated microservice sitting behind each one. This would then turn around and consume a common set of platform services. This can save you from having frontend-specific concerns in e.g. the review store layer. But it adds a lot of complexity, and as with all microservices architectures, you don't want to do this until your team is so big that you have to.

Answer 2

Generally speaking, a microservice should handle all aspects of a problem domain. You should not split up that activity into different services unless there is a really good reason to. So the 'reviews' service should handle moderation of said reviews. My understanding of a moderation event is that technically speaking it is just an edit of someone else's review.

In a REST API you should have separate create and update mechanics because the semantics are different. It also simplifies your case since a moderator is unlikely to create a review for another user.

It's not uncommon to see

if (existingReview.createdBy == context.user.userId) {
  // good, editing own review
}
else if (context.user.claims.containsKey('editReview')) {
  // good, holding privilege
}
else {
  return 401 Unauthorized;
}

What you can consider is different paths in the same API. This can be helpful when moderation has different fields than other edits. Think along the lines of Command Query Responsibility Segregation.