How to organize the architecture of microservices interaction?

Question

Software design

Colleagues, good day to all!
There is a spherical task to create a blog using a microservice approach.
Blozhik should be able to:
1) register and authorize users
2) create/read/edit posts
3) create/read/edit comments on posts.
The solution I see for myself is this:
1) a microservice - an aggregator - all requests from clients (browser, mobile phones, etc.) go to it. Then he makes requests to other microservices for data (Aggregator)
2) microservice for registering, storing, authorizing users. (User)
3) microservice for working with blog posts (Post)
4) microservice for working with blog comments (Comment)
Question: how best to organize the interaction of microservices with each other?
The following implementation comes to my mind:
- The user, being logged in on the blog, enters his blog. Aggregator accepts his request.
- Aggregator calls User to check authorization and fetch the name of the current authorized user
- Aggregator goes to Post to get a list of posts
- Post (or Aggregator?) goes to Comment to get a list of comments for each post
- Comment (or Aggregator?) goes to User to get the full name of commentators
But I don't understand how to achieve maximum atomicity and isolation of microservices. When one of the microservices crashes, this should not put the entire application down - with the microservices of posts and comments, everything is more or less clear to me, but the User service confuses me a lot, because he participates in the authorization and obtaining the full names of the authors of the posts and commentators. It turns out - this is a bottleneck - when the User service crashes, the entire application will fall off:
1) you can not authorize other services
2) it is impossible to display a list of posts or comments without the names of their authors.
What do you advise?

Answer 1

You don’t need to make a blog on microservices, either for educational purposes or for combat ones.
Everything that you described about the blog - comments, users, posts - is all rather strongly related data, and it makes no sense to process it in different services. In the solution that you proposed, everything will be fine, if you replace the "microservice" with the "controller" (which is from MVC), there will be a classic solution to the learning problem.
We need to come up with a task where the services will be more independent of each other. Then you will not suffer to understand how to make services more autonomous. Ideally, any service can continue its work, and implement all or part of its functions, if other services are down. It’s good, for example, if the interaction between services A and B is implemented through a message queue - then the fallen service B, after raising it, will rake up this queue and do everything that service A managed to ask from it while B was lying.
You can also talk a lot about authentication for a long time, usually in order to live for some time without an authentication service, it is done using tokens (JWT for example). Then the target service itself can check whether the person is authorized or not.
If you really want a blogger, then I would leave it alone as an independent service, and as other services I would do:
- notifications of new comments / posts in the messenger / mail (it would be just fine to communicate with the main service through MQ);
- some elementary analytics, which is independently collected, for example, by visitors, telemetry is shorter;
- autopost service - you order a post with the desired content for a specified date and time, this service uses the API of the main blogger service and posts something without your participation.
Here is something interesting. Please note that perhaps all of these three services can work without the main one, and vice versa - the main service can queue messages for other services (1st and 2nd), and the services will clear this queue while they are working.

Answer 2

1. implement the User service in such a way that there is no SPF
2. choose a more adequate task for such an architecture

Answer 3

With this approach, all the logic will lie in the aggregator, but in fact all it has to do is understand to whom the request came and send it there, and that service will already process it. 3/4 is one service, not two. 3/4 itself must go to 2, otherwise any logic for checking rights slightly different from userId!=autorizedUserId throw Forbidden() will fall on the aggregator or on 2. If you add another photo gallery, this will already be another microservice, it will have its own comments and his photos, for information about the user, he also goes to 2. Then if 3/4 is covered, then the photo gallery works, if the photo gallery is covered, then 3/4 works. If a comment is a separate service, then if it falls, all social ones fall, plus it is difficult to ensure atomicity / integrity, etc., so each service must have its own.