> I was thinking that it would also make sense to be able to pull the orders made by a particular user when you fetch the details for that user without having to make a separate API call to the orders MS with the user id in order to fetch the order data, but I guess this is the consequent network fetch problem that comes with a distributed system like microservice when compared with the monolith architecture pattern.
Hey -- it's a fair callout. Think of it this way -- do you need order data when you retrieve a user (every time you retrieve a user)? Likely not. Updating a user profile, resetting a password, sending an email does not require order data. This is what's called a bounded context.
I'm stepping into assumptions about your application based solely on the names, but generally you only want to retrieve orders data when you need the bounded context of an order. ("Get My Orders" for the user, "Get All Unshipped" orders for the admin, etc)
This is part of a Behavior-Driven design (see link above).
As for performance -- you may still be applying Monolithic patterns to your SOA design -- remember, the whole purpose of your orders service is to process orders. That's all it does, and it needs to do it well. Think of that FK->PK join in your query as the same as a database query, but instead of two tables, it's two services.
If the infrastructure is built correctly (using something like a Lambda, EC2, EKS/Containers) those services become elastic and adaptable to load. So you can scale up your users service separately from your orders (and/or vice-versa) and you can independently deploy patches & updates to each service without affecting the other. These are the benefits of SOA.
Happy to provide resources but I don't know where you are in your journey. It sounds like you're just starting out with microservices, but it's not my intention to talk down to you. :)
Some of my personal recommendations:
Also, if you search for "resources" in this subreddit, I believe there's a bunch there already