Which use case scenarios are the most appropriate for the publish/subscribe pattern? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

I am currently working on a social networking application that needs to be highly scalable.

I have been reading about the publish/subscribe pattern(message bus) and am struggling with understanding proper use case scenarios - when this would be appropriate and when this would be overkill?

For example:

• There are several areas of the site where users enter information on a form that needs to be saved to the database;
• When the database saving occurs and an email notification(s) must be made to one or more users.

Also, for the save scenarios, I would like to give the user friendly messages letting them know their data is saved on the form after saving process completes, if I were to go pub/sub approach.
How would I return success/fail messages back to the UI after a specific task completed?

Which scenarios are ideal candidates for pub/sub pattern? It seems to be overkill for basic form database saving.

Answer 1

From your two scenarios, the latter is a possible candidate of being implemented with a bus. The rule is - the more complex/longer processing takes, the higher probability is it won't scale when processed synchronously. Sometimes it is even the matter of not the number of concurrent requests but also the amount of memory each request consumes.

Suppose your server has 8GB of memory and you have 10 concurrent users each taking 50 megabytes of RAM. Your server handles this easily. However, suddenly, when more users come, the processing time doesn't scale linearly. This is because concurrent requests will involve virtual memory which is a hell lot slower than the physical memory.

And this is where the bus comes into play. Bus let's you throtle concurrent requests by queuing them. Your subscribers take requests and handle them one by one but because the number of subscribers is fixed, you have the control over the resource usage.

Sending emails, what else? Well, for example we queue all requests that involve reporting / document generation. We have observed that some specific documents are generated in short specific time spans (for example: accounting reports at the end of each month) and because a lot of data is processed, we usually had a complete paralysis of our servers.

Instead, having a queue only means that users have to wait for their documents a little longer but the responsiveness of the server farm is under control.

Answering your second question: because of the asynchronous and detached nature of processed implemented with message busses, you usually make the UI actively ask whether or not the processing is done. It is not the server that pushses the processing status to the UI but rather, the UI asks and asks and asks and suddenly it learns that the processing is complete. This scales well while maintaining a two-way connection to push the notification back to the client can be expensive in case of large number of users.

Answer 2

I suppose there is no definite answer to your question. IMHO, nobody can evaluate the performance of a design pattern. Perhaps, someone could consider comparing it with another design pattern but even then the comparison would be at least unsafe. The performance has to do with the actual implementation which could vary between different implementations of the same design pattern. If you want to evaluate the performance of a software module, you have to build it and then profile it. As Steve McConell in his legendary book suggests, make no decisions regarding performance without profiling.

Regarding the specific pattern and your scenarios, I would suggest to avoid using it. Publish-subscribe pattern is typically used when the subscribers do not want to receive all messages published, but rather some of them satisfying some specific criteria (eg belonging to a specific kind of messages). Therefore, I would not suggest using it for your scenarios.

I would also suggest looking at the Observer pattern. I suppose you could find many more references online.

Hope I helped!