This problem statement is around one UI component, 3 service components. The current design of the application is like:

  1. UI makes request to Service-A to get data
  2. Service-A first makes a call to Service-B to get list of items. There can be multiple calls between Service-A and Service-B if there are huge number of records. For example, Service-A asks service-B to return all avaialble items. Service-B will return data in pagination form i.e. first page will have 100 items, seconds page will give next 100 items and so on until all the items are retrieved. Here Service-A will specify the page number while fetching items from Service-B
  3. Once all the items are collected(in Step-2), Service-A will make call to Service-C to get details about each item. Service-C can have data for all items or only few of the items. Service-C also works on pagination like mentioned in Step-2.
  4. UI keeps polling Service-A for data in every few seconds to see if data is ready.
  5. Once Service-A has got all item details from Service-C, it sends data back to UI.

Above design results in a endless spinner on UI screen if Service-B and Service-C are slow in returning data.

Now I want to improve this design in a way that Service-A does not wait for both Service-B and Service-C to send all data and can return data to UI in chunks. There is no pagination on UI as of now but a scrolling based pagination can be added like load more data when user scrolls.

Could anyone please suggest a better way of implementing this flow?

Kindly let me know in case more details are required.

Thanks a ton in advance. :)

  • Not sure, why someone down voted my question without any reason. At least provide the reason of down voting or povide the solution to my design problem. – G.G. Oct 29 at 9:53
  • Is there a diagram showing where the reverse proxies are located between Service-A, Service-B and Service-C? – rwong Oct 29 at 12:50

It seems like the only problem is the slowness but its not clear why it is slow.

You have two possible approaches

Approach A, get all the data, but faster. Do this if the volume of data isn't a problem, its just looping through all the calls which slows things down.

  1. Can you turn off pagination in the sub services?
  2. Can you requests all the pages at the same time asynchronously?
  3. Can you cache stuff?

Approach B, stream the data to the UI in smaller chunks. Do this if the data volume is a problem

  • get (n) items
  • get its children/extra data
  • send to UI
  • update UI
  • repeat

You will probably want a combination of approaches, it sounds from your question like you are processing the data synchronously, its a simple step to stop doing that and request pages 1,2,3,..... etc at the same time rather than processing page 1 before moving to page 2 but this will likely overload your services unless you have some sort of rate limiting.

Similarly taking approach B can lead to very synchronous code.

Your code needs to be aware of the rate limit at which the sub services can provide data.

If they have capacity, request the next n items and start work on them. Even if you haven't sent the first ten yet.

If they don't have capacity, don't ask them for out of order data which you wont be able to send because the first chunk isn't finished.

Avoid waiting for that one last child item before requesting the next ten items but also avoid requesting the next 1000 items when you haven't finished with the first 10 yet!

Obviously you also have Approach C, request everything at once, send the main items without child items and then update the UI with the children later.

I wouldn't normally go for this approach as presumably the UI needs that extra info to perform its function. Showing the parent and later showing the children is just a different kind of spinner

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.