Currently there is a users microservice in my project, which handles all the authentication logic and stores user data (email, name, bio etc.)
One of my application's features will be posts. I want posts to be contained in a separate microservice, which will use a separate database, storing just the user ID. However, that would require doing two HTTP calls:
It is big overhead, when just updating the feed. Maybe it is worth to combine the microservices, or to use one database for both posts and users?
As most of the answers in the field of architecture - there is no "correct" way, it's all about trade-offs and what you're willing to pay.
For example - separating the posts and users to be consumed from 2 different services actually causes http calls overhead as you mentioned, on the other hand - deployment, testing, and maintenance in general will be much easier if you have 2 different services - a small change in the users service has no impact on the posts application. If you combine them to one service - you can't enjoy these advantages.
As a rule of thumb (but again, it's not true for all cases) - in microservices, a different response's model usually indicates on a different service (again - ease of deployment, testing, and maintenance), so it makes sense for me to separate the users and posts services. However one thing you can combine is the database - you can put users and posts in the same database, but in different tables of course. In that way you're still separating the models, but enjoying the privilege of have the data in the same repository (joining tables, etc.).
In addition, if you're really concerned about the http calls from posts service to users service, you can consider caching which will help to reduce the calls overhead.