4

I am designing a whatsapp like messenger application for the desktop using WPF and .Net. Now, when a user creates a group I want other members of the group to receive a notification that they were added to a group. My frontend is built in C#.Net, which is connected to a RESTful Webservice (Ruby on Rails). I am using Postgres for the database. I also have a Redis layer to cache my rails models.

I am considering the following options.

1) Use Postgres's inbuilt NOTIFY/LISTEN mechanism which the clients can subscribe to directly. I foresee two issues here i) Postgres might not be able to handle 10000's of clients subscribed directly. ii) There is no guarantee of delivery if the client is disconnected

2) Use Redis' Pub/Sub mechanism to which the clients can subscribe. I am still concerned with no guarantee of delivery here.

3) Use a messaging queue like RabbitMQ. The producer of this queue will be postgres which will push in messages through triggers. The consumer of-course will be the .Net clients.

So far, I am inclined to use the 3rd option.

Does anyone have any suggestions how to design this?

istepaniuk
  • 4,016
  • 2
  • 32
  • 60
Ashish Menghani
  • 49
  • 3

1 Answers1

0

In an application like WhatsApp itself, the client running in your phone is an integral part of a large and complex event-based, distributed system.

Without more context, it would be impossible to point in the right direction. That said:

  • For option 1: You seem to imply that each client, as in a WhatsApp client, would directly (or through some web service) communicate with Postgres as an event bus, which is not sound and would not scale because you can only have ONE Postgres instance.
  • For option 2: You have the same problem that in option 1 with worse failure modes.
  • For option 3: RabbitMQ seems like a reasonable ally here. It is distributed in nature and scales well. As a matter of fact, it runs on erlang just as most of WhatsApp does. Using triggers inside Postgres to publish messages however does not make a lot of sense.

You need a message bus because you would have lots of updates to do in the background, not to directly connect your users to each other. As you said, clients can be offline.

Architecture is more about deferring decisions than taking them.

I suggest that you start simple. Build a small, monolithic, synchronous system first, pushing updates as persisted data to all the involved users. For example; In a group of n users, just write n records to a table. It is already complicated to reliably keep track of who has received and read what.

This heavy "group" updates can then be moved to long-running processes using RabbitMQ or the like, but a system with several thousand users can very well work without such thing, especially because a simple message from user A to user B would not need many writes.

istepaniuk
  • 4,016
  • 2
  • 32
  • 60