Proper separation of concerns between microservices

Question

Let's assume I would like to create a blogging platform that would allow managing user accounts, therefore I came up with 2 microservices:

• Blogging - managing posts, tags, etc.
• Users - managing users, their roles, etc.

It's clear to me that Post contains the ID of the author (User) and User contains IDs of the Posts he wrote.

The problem is that when a client requests a Post, I would also like to return the name of the author and send it together to the client in a DTO (view model). I see 2 possible solutions for that:

1. Introduce the concept of the User (only ID and name) in a domain of the Blogging service. Every time a client requests a Post, all relevant data is fetched only from this microservice. Every time a user's name is modified in a Users microservice, this service is notified and updated author's names.
2. Keep the concerns completely separated. Every time a client asks for a Post, Blogging microservice is called to fetch Post and then Users microservice is called to fetch the author's name based on the ID.

So far I was leaning towards solution #1 as it would require only 1 call to the 1 microservice when Post is requested, but then let's say if the number of functions (microservices) starts growing and I keep adding small concepts from each of them only to limit the number of calls, I'm afraid I would end up in a spaghetti Blogging microservice... But then I also don't think the number of microservices will grow significantly ;)

Which way do you find better and why? Does any of the approaches break the microservices architecture principles and my concerns are justified?