3 ms·
> It is true that Zulip writes a tiny UserMessage table row with (user_id, message_id, flags) for every active recipient of a message, we need to do so in order
by darkwater 6y ago
> It is true that Zulip writes a tiny UserMessage table row with (user_id, message_id, flags) for every active recipient of a message, we need to do so in order to track the unread state for all of those recipients (as well as related details, like mobile push notifications state). We need to write to that row a second time when the user reads the message.
No software architect here so I might be completely off the target but, is not read/unread count something that squares perfectly with the "eventually consistent" model? You don't need to write it down to the persistent storage right now as long as the client UI has it, then some kind of cache has it (so mobile can be in sync when refreshed) and then you persist it to the DB.
- tabbott 6y agoWe could certainly do something in that direction, but it'd be a lot of complexity (and risk of synchronization bugs) to avoid a few ~10ms of latency when sending messages to very large audiences. Especially since that latency is mostly invisible, thanks to local echo: https://zulip.readthedocs.io/en/latest/subsystems/sending-messages.html#local-echo https://zulip.readthedocs.io/en/latest/subsystems/sending-me... It's also not very high-value to optimize; that database write is 10-20% of the total time to process sending a message to everyone in a large open community like chat.zulip.org (with 18K total users).