Design choices for chat application using Redis & Websocket

In this video, I have talked about key design choices when you build a scalable chat system. This is around real time chat application.

FRONT END TO BACK-END
To make this communication fast, you can you use web-sockets from front end to backend. I have created a video on how to create a chat application using pure web-sockets. You can go out and check it.

BACKEND TO BACKEND
There are multiple options to send message from one machine to other:
1. Calling the API of another machine.
2. Pub-sub
Calling synchronous API of another machine has a lot of disadvantage:
1. How will the sender know which machine a particular user is connected to. These servers will keep on going down and coming up. The user will also connect to different server in each session.
2. The ack from all the dependent machine will take time and hence the ack of getting the response will be low.
3. The operation can be partial success and there is no way to retry.
Hence pub-sub is preferred.

DESIGNING CHANNELS
We design channels in a way that is decoupled and fault tolerant.

Here is another video on implementing chat on a single server: https://youtu.be/sj9kJdFAVDY
00:00 Introduction
02:03 Problem statement
04:22 Why web-socket in frontend
08:11 Why pub-sub in backend
13:18 backend data flow
14:45 1 channel Vs multiple subscription
19:28 summary
22:03 Thank you

Follow me on Linkedin: https://www.linkedin.com/in/anubhavsri/
You can also DM me if you need guidance as a software engineer.

[Tags]
software engineer
redis pub sub
chat application
system design,
software engineering for beginners,
software engineering full course
redis cache interview questions
backend engineering explained
redis pub sub websocket
software engineer interview
software engineering
backend engineering interview questions
backend engineering interview
system design
real time chat
interview preparation
real time chat application
design interview,
software interview