I am curious for solutions to this problem:
Assume we are going to build an online-store. To better scale parts of the architecture, it is broken into independend subsystems. The typical scenario would involve an application server (or something similar), where the requests from clients come in.
The flow for a login would be something like this:
Request comes in
->Get last products a user bought
->calculate appropriate ads
->deliver generated Page to client.
This is less efficient, because the queries of the subsystems happen in a serial/synchronous way. It would be better, to make calls in parallel.
For example one could use a Node.JS server and call the subsystems asynchronously. On callback there is something like a "reduce function" called, which aggregates all data and, when all data is collected, it sends the generated page back to the client.
So this system seems more efficient.
Another step would include further decoupling and introduces message queues.
So there is on the one side the application server, which gets the requests and serves the replys; and on the other hand, the independend components communicating over message queues.
The flow would be the following:
->Message: "User with session key 1234567890 is granted access"
So with the session key, the user and according messages are identifyable. This message is taken by the user-service and produces the answer "User with session key 1234567890 is John Doe from New York". This message is published to all the other services in the application. So they can react and publish their results.
My Problem is, how do I route the result back to the application server which has to wait an unknown amount of time? How does it know, when to collect all the results for its request?
One solution could be, using an in memory database (e.g. Redis). All services could write their results into Redis, which is constantly polled by the application server while waiting for a result to deliver. But, is that the solution?
Are there other solutions?