Vishwa Bhat

Technology Enthusiast

Feb 20, 2019

What are the advantages of caching chat messages when users send new > messages every second?

If you perform reads from DB for the real-time operations like Instant Messaging, it would be expensive. Secondly, you'd face concurrent DB write issue because of Locks. Cache reads are Faster.

If you cache too many messages on redis wouldn't this be a problem?

You'd usually store latest X no. of messages in cache of every channel/workspace depending on the use-case. Whenever you receive a message, you'd broadcast the write request on both Cache and DB asynchronously through Queues or similar approaches.

What if server go down or some error occur? Am i going to miss all the data from redis?

As mentioned above, you'd always write on DB along with Cache since Cache cannot be used as a persistence layer.

I'm not sure if Slack uses Redis only for Caching or it also uses it for Pub/Sub module in Redis. Pub/Sub module follows Publisher-Subscriber pattern where online Users will be subscribed to all channels they're part of and when a user posts a message to a channel to which other users are subscribed, this message gets broadcasted to all the subscribed online users of that channel.

Serdar Sanri

Sr. Frontend Developer

Feb 21, 2019

Addition to this, you don't need to use socket.io if you are using redis. Redis already comes with pubSub.

jarupong pajakgo

I'm a noob web developer

Feb 22, 2019

Serdar Sanri Why you think that he doesn't need SocketIO?

Socket IO is real-time backend framework which client and server communicate immediately.

First of all socket.io is not a framework but html5 websockets server and client library. If we call it framework than it won't be fair to .net, symfony, laravel, spring and many others. As a library it opens a socket port between client and server to send message packages to all connnected clients and it is a greaat tool. But to me, still unstable and opinionated. If you have socket.io server than only option for client is their own client script.

Meanwhile Redis already provides a pubSub event emitter. You subscribe and listen to events, when data changes or added to redis, it notifies all subscribers. npmjs.com/package/node-redis-pubsub is a great node implementation.

Long story short, if OPs main concern is updating clients based on Redis cache, adding socket.io in the middle is unnecessary. But if the concern is also usin websockets to communicate between client to client or other functionality outside of redis, websockets will be the way to go. But still socket.io won't be my first choice.

Search Hashnode