Chat app database architecture [closed]

Question

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

---

Want to improve this question? Guide the asker to update the question so it focuses on a single, specific problem. Narrowing the question will help others answer the question concisely. You may edit the question if you feel you can improve it yourself. If edited, the question will be reviewed and might be reopened.

Closed 3 years ago.

Improve this question

I understand that chat apps are a fairly well understood and architected thing. I’m looking for some best practices advice on structuring the backend, particularly as it relates to user inboxes.

1. One thing I’ve seen is that many chat services will duplicate a message across a user’s inbox. For example, in a two person chat— each will get a copy. In a 4 person group chat, a single message is saved as four. Why is this, and are there downsides to not doing this?

2. My main database is Postgres. Is this the wrong tool for the job given the large volume and throughout of messages? We already use this for user data, so it’s certainly convenient but I’m guessing it’s not the best for messaging.

3. I’ve also seen some chat applications do one websocket connection per user per thread— meaning that in a two person group chat, two different websocket channels are opened and two different messages are sent (containing the same content). What is the purpose of this? Is it the best practice for a consumer chat application today?

• Stack Exchange Broke The Law: regarding point 3, how else would you possibly do it?
• Doc Brown: Asking three different, only loosely related questions in one post is not ideal for the Q&A format of this site. But even if you asked #2 and #3 individually, they were probably closed as "too opinotated".

Answer 1

One thing I’ve seen is that many chat services will duplicate a message across a user’s inbox. For example, in a two person chat— each will get a copy. In a 4 person group chat, a single message is saved as four. Why is this, and are there downsides to not doing this?

1. Per user copies allow users to have their version of Inbox. Easy to delete some messages or chat threads only for some users.
2. Data is separate per user, every user has a copy of inbox. Means each user's inbox can be on a separate shard of the database. Shards have been known to help with massive data volumes.
3. In such setup, sending a message is essentially a Fan-Out. The new message posted from sender's inbox is propagated in parallel to others inboxes, without the sender waiting/caring for it.

My main database is Postgres. Is this the wrong tool for the job given the large volume and throughout of messages? We already use this for user data, so it’s certainly convenient but I’m guessing it’s not the best for messaging.

A fine tuned PostgreSQL is almost as competitive as any other database in terms of volume and throughput. Most chat oriented databases are rarely doing anything exceptional in storage department that PostgreSQL isn't already doing.

They just have additional services wrapping something like PostgreSQL with pub/sub and event oriented capabilities that user's don't have to implement themselves. Firebase is one such example.

I’ve also seen some chat applications do one web-socket connection per user per thread— meaning that in a two person group chat, two different web-socket channels are opened and two different messages are sent (containing the same content). What is the purpose of this?

Something that makes sense is one web socket per active user device.

On a single active device, multiplexing of many kinds of events or messages over a single Web Socket is possible. As a bare minimum, a single app instance on a device can send and receive all communication with server over a single web socket. It can even post messages using plain HTTP and only use web socket to listen to server side (incoming) events.

The second variable is number of participants. Consider a group chat with N participants with each participant user has the messaging app running on M devices (For example, they have 2 phones and also a laptop and app is running on all of these). This means a minimum of N*M web socket connections would be established.

Sending same message to all participants over separate connections would only make sense in full Peer-To-Peer communication where central server is only helping discovery and users are directly interconnected via web sockets.

Is it the best practice for a consumer chat application today ?

The best practice is that which works for you.