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

->Authenticate user

->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:

Incoming Request

->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?

1 Answer 1


In the example you use there is nothing that can be parallelized. Each step requires data from the previous. Hope you are using better example for your design drafts.

The direction in which you are heading requires quite elaborate orchestration (as you have realized yourself) and this is non-trivial problem. One possible technical option is to use temporary queues — the front server creates temporary destination for the user session, then provides it as reply destination to the sub-tasks. This type of solution requires lots of care around the handling of the destination life cycle — thinking about timeouts, abandoned sessions, dangling temporary destinations, as well as fail over on the coordinator side (the front server). Hypothetically you can build tree of steps using this pattern but be very careful to control the interaction complexity.

Broadcasting (in it's broad meaning) in highly distributed system with expected high load is to be avoided. You will have to factor in some natural (hence cheap) partitioning in the message stream designs. Example of such partitioning is the round-robbin queue behavior in the mainstream JMS brokers.

I would definitely not broadcast the authentication attempt as this is gonna be very easy to be abused by DOS attack.

Alternative would be to render placeholders in the webpage for each portlet (advertisements, recent purchases, so on) that request the data on page load and leave the orchestration to the browser. It is so simple that no other solution beats it's cost/benefit ratio.

I am not sure how relevant this is — be careful to know very well why you are cutting the system in the particular way you have chosen. The boundaries of a service is extremely important decision because if done wrong it has long lasting negative effect and it's very hard to be fixed. If you haven't done it before, invest the time to research the SOA literature on methodologies for defining service boundaries. Regardless of the technology you plan to use.

  • This is not an actual architecture, but rather a theoretical model I was thinking about - I am no architect ;) . »Alternative would be to render placeholders in the webpage for each portlet (advertisements, recent purchases, so on) that request the data on page load and leave the orchestration to the browser. It is so simple that no other solution beats it's cost/benefit ratio.« It's so simple I had not thought about it xD Thank you very much! Jul 16, 2015 at 16:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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