Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
sawmurai16515dYou 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.
gitpush3424315d@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?
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.
stop527415dIs 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.
meseguer199829Nobody: Senior frontend Dev at my company: "microservices best thing ever" Also him: "Relational databases g...
skiilaa4The 2014's called, they want their private server back! Source: CommitStrip
fthielen0Oh, i have to get up in about 5 hours for work, but hey, now i know what microservices are 😅