My question of the day is about combinatory operation when building microservices.
Let us use the fictionnal scenario : I want to build a dashboard. The dashboard is composed of a bunch of people and their infos (history, reviews, purchases, last products searched).
Reading spring-cloud and spring-reactor, I would like a non blocking solution calling multiple microservices : user service, review service, search engine service, ....
My first guess was to do something like
- load the users,
- for each one load its reviews then
- load its history then
- combine all the data
In pseudo-code something like loadUsers().flatmap(u -> loadReviews(u))....reduce(). It's really approximative here as you can see.
When loading 1 user, we can estimate that we need 4 more http calls. For 100 users, 400 additional calls etc etc. The Big-O doesn't seem linear.
In the worst case where a microservice also delegates data loading from a XYZ microservices then we have got : for 1 user -> N calls including 1 review call -> 1 XYZ call. Sorry I didn't calculate the Big-O (quadratic ?).
To avoid that, we can perhaps load all the users, extract their id, call earch microservcies with a batch of ids. Each microservices can load all the data at once (List of reviews mapped by id perhaps) and the original called will merge all theses lists. (a kind of zip function)
Summary : I just read this question about Observables composition. My question is can be summarize with "Do you use the same strategy when you don't have a unique user at the start of the chain but hundreds of users ?" (the performance can be a problem no ?)
