Microservices

Lets take an example: Products service & orders service.

When I want to save an order for a user, data saved as
1. UserId, ProductId, Quantity, Date

Or
2. UserId, Name, Email, ProductId, ProductName, Quantity, Date

I'm a bit confused here because if I'm going to fetch that purchase, in example 1, it will return IDs requiring another trip to server to get user & product info

In example two it takes only one trip BUT if any changes is made to either user info or product info it means I'm returning wrong info to the user.

What do we do in this scenario? Excuse my questions first time applying Microservices and been using monolith all my life

You can basically replicate some of the data in the background. Service b might only need a subset of the data of service a. There might be scenarios where service b has an outdated version of that data.

Another alternative is to look up those ids in the frontend or backend. But services calling other services before returning a result to the client is a recipe for slow response times.

Microservices tend to encapsulate vertical slices of a business concern that in many cases would exist in single domain in a monolith. Sometimes the domain is shared, sometimes it isn't.

In this particular example, the answer has to be derived from the consumer; at what level are they expected to understand each domain isolate?

Microservices can in fact form dependencies on each other in any number of ways:
1. event streams
2. direct dependency queries
3. cache intermediaries
4. Actor sharing
5. 4-5 less common approaches

If the consumer is expected to know that both segments exist, they are also expected to know the data freshness concerns between the two services.

There's actually a missing abstraction here: the cart service. The cart service should represent a normalization of the two dependent services and be responsible for taking 1...N orders and collapsing them into a single finite order for the individual consumer at the time of checkout, ensuring cart validity along the way. This can be done in a number of different ways.

@SortOfTested Thanks for detailed info, all good for that point. But what about what @sawmurai said: "But services calling other services before returning a result to the client is a recipe for slow response times."

For example assuming user fetched product list and that one item left in stock was available, but by the time user placed order, that item is no longer in stock. Orders service will need to check products service if it there are still items in stock and respond accordingly.

Doesn't this result in slower response? Or its the usual: If said service is busy, not available or network is overloaded. Else it will not have an impact.

Also is it the right way to do: Orders call products to check stock status and act accordingly?

@gitpush
It's not ideal, but it's also a pre-optimization to worry about that during the design phase. Properly scaled services in the same network segment should have marginal latency and also potentially have parallel execution of other distributed tasks. It's low risk/effort to experiment and see since they're discrete tiers to begin with; solutions are always space/time tradeoffs in this condition.

The optimization is event streams. Keeping time stamp indices in a query store that can be called from the ordering service, as an example, can allow the error to be corrected at any point during the shopping process (add item, update quantity, remove item, apply code, view cart, etc). You've likely seen this happen on sites where you'll see messages like "an item has changed in your cart."

Kafka is your friend in this scenario.

@SortOfTested I understand, thank you so much appreciate your help :D

Is it just me or would it be usually
1. userid, authinfo, name, ...
2. itemid, price, quantity, datetime, userid
3. itemid, price, iteminfo.
I made the price in table 2 and 3 to be able to change prices without to care about the old purchases.