YT YouTube2Text

YouTube2Text → Transcripts → Websocket, SSE e Polling: Atualizações em tempo real para entrevistas (System Design #4)

Websocket, SSE e Polling: Atualizações em tempo real para entrevistas (System Design #4) — Transcript

by Pedro Camaforte · 4,226 words · 639 segments · language pt-BR · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Imagine if, when you're chatting with
0:02someone on WhatsApp, you had to keep
0:04reloading the screen every time to see
0:06if a new message arrived. That would be
0:08awful, wouldn't it? And it's not
0:10supposed to be like that. Messages are
0:12meant to be in real-time. They should
0:13happen in real-time. If I send a
0:15message, I expect the other person to
0:16receive it right away. And if they send
0:18one, I receive it right away. And that
0:20is exactly what we're going to talk
0:22about in today's video. Real-time
0:24updates. When we stop to analyze the
0:28big companies we have in the market
0:30today, it's expected that this concept
0:31would come up so often in interviews.
0:34Because, for example, Google Docs, when
0:36we have multiple people editing the
0:38same document in real-time, or Figma,
0:39for example, when multiple people are
0:41dragging elements around, we can see
0:43the cursor exactly where the person is
0:45in real-time. Uber, so we can see the
0:48driver's exact location in real-time as
0:50well. Or, for example, iFood, when
0:52we're watching the status of our order,
0:54when the driver left to deliver our
0:56order—all of this happens in
0:57real-time, and all these companies use
0:59this type of architecture. And that is
1:01exactly what we're going to talk about
1:03today. We're going to cover
1:05architectures and concepts like polling
1:07, server-sent events, and web sockets.
1:10But while most people stop there and
1:12just talk about this in the interview,
1:14we're going to go a little deeper and
1:15understand some details that will
1:17surely earn you some extra points in
1:18the interview. Unfortunately, there are
1:21many silly mistakes people make because
1:23they're nervous or because they forget
1:24things during the interview. And that
1:26is exactly what I want to avoid. I want
1:29to leave you 100%prepared to answer
1:30this kind of deeper questioning during
1:32interviews, and by the end of this
1:34video, you'll understand which mistakes
1:36people make most often and how to avoid
1:38them. Nice to meet you, my name is
1:41Pedro Camaforte, I'm a senior developer
1:42, and I've been working for companies
1:44abroad for almost two years now. And
1:47this is our fourth video in our
1:49seven-video series on the main system
1:51design concepts that come up in
1:53interviews for big companies, for
1:54top-tier companies—that is, companies
1:57that will pay you 20, 30, or 40,000
1:59reais and up. If you missed the other
2:02videos in the series, the playlist is
2:03here in the description. So let's get
2:05started. Our first strategy that we are
2:07going to cover here is the polling
2:09strategy. Super simple, super basic.
2:11I'm sure most people have seen it or
2:13already implemented it, and know how it
2:15works. But polling is nothing more than
2:18firing an HTTP request to the server
2:20every x seconds to ask if there are any
2:22updates, if there is anything new. So,
2:25for example, we will ask if there are
2:27new notifications to show to our user.
2:30So, we can, for example, set an
2:32interval in our code and every 5
2:34seconds make a call to check if there
2:36is a new notification. If a new
2:38notification exists, we go ahead and
2:40update our screen. Then 1, 2, 3 new
2:42notifications appear there in our UI.
2:45So, for non-critical flows, for
2:47notification systems, for reporting
2:49systems, this is a super valid strategy
2:52. When we don't have that many users
2:55logged in at the same time, polling is
2:57super viable because it's super simple,
2:59it's not complex at all, and it meets
3:01the momentary need we have right there.
3:05We don't need a critical flow, we don't
3:07need to know the exact moment a
3:09notification arrived for our user or
3:10that a report is ready for us to
3:12download. It's okay if we have a little
3:16delay of 3, 5, 8 seconds; it's not a
3:18problem. Polling already meets this
3:20type of need. I remember back at the
3:22beginning of my career, when I was a
3:24junior, I had to implement a polling
3:26system for a report screen, so the user
3:27wouldn't need to reload the page to see
3:29the report available to download. I
3:32looked at it and said: "Wow, what a
3:33horrible architecture, what a horrible
3:35system, it's going to keep wasting
3:37requests and nothing will happen on the
3:39screen." Most of the time the user
3:41isn't even downloading the report. Wow,
3:43horrible. Until I saw a senior
3:46developer there with over 8, 10 years
3:48of experience saying that polling is
3:50exactly made for this type of situation
3:52. And seniority is about that. It's
3:54about understanding that simple
3:56problems require simple solutions. If
3:58we need something more advanced, there
4:00will be a more appropriate solution.
4:02But for systems like this, systems at
4:04this level, polling is totally
4:06reasonable for us to use. Because if
4:09our demand is very low, there's no
4:11point in setting up a web socket to
4:12update in real time the moment the
4:14report is ready. There are 10 users
4:17using our system. So polling is 100%
4:19effective for this type of case. Don't
4:21be afraid to mention this during an
4:23interview. If the interviewer tells you
4:26there are 1,000 users connected to your
4:27system and it’s just a simple system
4:29to show them a notification, polling is
4:31perfect for that. There’s no reason
4:34to make things up or talk about
4:35server-sent events. Just say that
4:38polling solves it. That’s what they
4:39expect from you. But, of course, most
4:42things have a tradeoff. And what is the
4:44tradeoff of polling? As we already
4:47mentioned, high latency and low
4:48precision. So, imagine if we were to
4:50use polling in an Uber system, for
4:52example. Imagine if we updated the
4:54driver's location every 10 seconds; the
4:56car would be jumping, skipping around,
4:58instead of us seeing exactly which
5:00street it’s turning onto in a smooth
5:02motion, exactly in real-time. So,
5:05polling is not suitable for types of
5:07systems that require that perfect
5:09real-time coordination. And also
5:12because it ends up wasting resources
5:14when there are many active users at the
5:15moment. Polling also won't scale, okay?
5:21It works for notifications, but if you
5:22have 2 million users connected to your
5:24system at the same time, polling will
5:26end up putting a heavy load on your
5:28server with ghost requests that aren't
5:29doing anything, but are there accessing
5:31your database and consuming resources
5:33from your database and your server. So,
5:37for this type of situation, it's also
5:39not highly recommended. It would be for
5:42a medium or small-sized application,
5:43for simpler things that aren't as
5:45sensitive to latency. It’s also worth
5:48mentioning another really cool strategy
5:50, similar to polling, which is long
5:52polling. Long polling is nothing more
5:54than the same thing that polling does,
5:56an HTTP call to the server. But the
5:59server, instead of responding instantly
6:01with a positive or negative result,
6:03will hold that connection for 20 or 30
6:05seconds. When it has something to
6:08return to the client, it sends it, and
6:09then the client updates in near
6:11real-time. It’s a bit more precise
6:13than polling because it keeps that
6:15connection open and receives data
6:16exactly when the server has something
6:18new. But it’s also something that
6:21doesn’t scale; it’s something that
6:22wasn’t built to scale infinitely. So
6:24much so that most companies, when they
6:26want this type of strategy, turn to the
6:28next concept we’re going to talk
6:30about, the next strategy, which is
6:32server-sent events. When we want a more
6:36precise update, so that when something
6:38changes on the server it automatically
6:40and instantly changes on our client, we
6:42use the SSE strategy, Server-Sent
6:44Events. It is perfect for when we want
6:49to wait for something to happen on the
6:51server, some change, and we want to
6:52update our client in real time
6:54instantaneously. There's no more delay,
6:57no more waiting. How do we do this? Our
7:02browser's API has this EventSource here
7:04, this special class, which we use to
7:06make an HTTP request to one of our
7:08server endpoints, and we keep listening
7:10for changes at that endpoint. So,
7:15whenever it sends us word that
7:16something has changed, in this case
7:18that a new notification has arrived, we
7:20parse that data in our example and show
7:22the notification to our user, all
7:24happening instantaneously. So,
7:27Server-Sent Events are great for, for
7:29example, financial market applications,
7:31where we want to keep track of stock
7:33prices in real time. We cannot have a
7:35delay. We need to know exactly when a
7:38stock price is going up or down, or
7:39charts that we want to keep monitoring:
7:42the status of our application, our
7:43server, or our database resource usage.
7:46We want something happening in real
7:47time there. Server-Sent Events are
7:50perfect for this because they are
7:52simple and scale very easily, much
7:54better than polling. If you're
7:57wondering how the server will send the
7:59events to our frontend, we'll get to
8:01that; we'll talk about it later in our
8:02next concept. But first, let's talk
8:05about the tradeoff. The tradeoff of
8:07Server-Sent Events is that it only
8:09carries text, so it doesn't carry
8:11binary, for example, which we will
8:13comment on in our next concept, as it
8:15has more capacity than Server-Sent
8:16Events for data transfer. And most
8:20importantly, it is a unidirectional
8:22communication, so it is always from the
8:24server to our client, never the other
8:26way around. Our client can never talk
8:29to our server and send things there. It
8:32is always just us listening to the data
8:34the server sends to us. So, for certain
8:36types of applications, such as chat
8:38apps, where we have one user sending
8:40and another receiving in real time, and
8:42then they reply and the other receives,
8:44it doesn't make sense anymore. We can't
8:46use it, because it's always the server
8:48sending to us and not us to the server.
8:50For this, we'll need a different
8:51strategy. And that other strategy is
8:54our great and beloved Web Socket. Our
8:57Web Socket will allow us to have
8:59bidirectional connections. So, both the
9:02client and the server can exchange data
9:04with each other. I, as a client, can
9:07send data to the server and the server
9:09can send data to me. And how does it
9:12work? Just like Server-Sent Events,
9:14we'll have a specific Web API to work
9:16with Web Sockets. Notice that the
9:18protocol is different; it's no longer
9:20HTTP. So, we can create this chat
9:23object here with 'new WebSocket'
9:25pointing to our host. And then we can
9:28both listen for events that the server
9:29sends to us. So, whenever it sends one,
9:32I'll convert the message here. And I
9:34noticed here, look, it's a message from
9:36Ana, she said: "Hey, how are you?" I go
9:38there and put it inside my chat. Can I
9:40send it back to the server? So, my chat
9:42. Send, I'm here sending a reply
9:45message to Ana. I'll say the type here
9:47is message and say here, hey, all good.
9:51So we can have this exchange, we can
9:53reach another range of applications,
9:54such as chats and real-time
9:56collaboration. So if you were wondering
10:00what Google Docs or Figma use under the
10:02hood to have this, to have this type of
10:04application, this type of strategy, it
10:06is exactly Web Socket. So as an
10:08advantage here, we have the
10:10bidirectional connection, which is
10:11totally distinct from the other
10:13strategies. Latency, just like
10:16Server-Sent Events, is practically
10:18instantaneous, under 500 milliseconds.
10:21And besides text, it handles binary
10:23frames if that's a need for our
10:25application. And how does this Web
10:27Socket communication work? Because I
10:29mentioned here that the protocol is
10:30different. Actually, the websocket
10:33starts with an HTTP request, but in the
10:35request header, it sends this: an '
10:37upgrade websocket' and a 'connection
10:39upgrade'. So what is it going to do? It
10:42will open this initial HTTP connection,
10:44but then it will change, update to a
10:46TCP connection. And then it will keep
10:50this connection open with our server in
10:52a tunnel format, a tunneling, and then
10:53both can freely exchange data with each
10:55other. This last header here is just a
10:58header that is normally sent to verify
11:00if the server is capable of handling
11:02WebSocket connections. It sends a key
11:05to the server to validate, and then it
11:07revalidates that key to see if the
11:09server converted or processed it
11:10correctly. So, with this, we can keep
11:13this connection open with the Socket
11:15and its specific protocol, which makes
11:18it very, very, very efficient and fast.
11:21But since not everything is perfect, we
11:23also have difficulties and tradeoffs
11:25when working with WebSockets. And the
11:28main one is that it is more complex and
11:29requires specific infrastructure. So,
11:33we will have certain difficulties
11:34working with it, unlike Server-Sent
11:36Events, it's a bit different. Let's
11:38understand what these complexities are,
11:40what these extra difficulties are that
11:42we will face. Let's imagine the
11:43following scenario. Imagine we have a
11:46server with 16 cores, 32 GB of RAM, and
11:49our messages have a size of about 1 KB,
11:52so roughly 1,000 characters. And in
11:55total, all the people connected to this
11:57server, all the connected WebSockets,
11:59will be generating about 100,000
12:01messages per second. Based on these
12:04calculations and data, we can reach
12:07about 300,000 to 500,000 simultaneous
12:09connections on this server, which is a
12:11very cool value. But how many
12:14simultaneous connections do you think
12:16WhatsApp keeps open per day? Much more
12:19than that. And for that, we will need
12:22to expand our servers and perform
12:24replication so we can meet all our user
12:26demand. So, just like any other
12:30application, we will replicate our
12:32servers to have more redundancy and
12:34allow more users to connect to our
12:35application. To route our users, we
12:40will need a load balancer. But this
12:43load balancer has a characteristic; it
12:45won't be a conventional load balancer.
12:48Normally, when we have servers serving
12:51standard HTTP requests, or the typical
12:53API calls we see in other systems, they
12:55are layer 7 load balancers, meaning
12:57they act at the application layer. For
13:01WebSockets, it's different; we will
13:03have to use layer 4 load balancers.
13:05This makes all the difference when
13:06mentioned in an interview. The goal of
13:10this video isn't to explain exactly how
13:12load balancers work under the hood, but
13:14it's important for you to know that
13:15load balancers typically have seven
13:17layers, and that HTTP calls happen at
13:19the seventh layer, while WebSocket
13:21calls happen at the fourth layer. And
13:24why can't WebSockets happen at layer
13:26seven? Because when a client makes a
13:29request to our server and the load
13:31balancer is in the middle, it takes
13:32that request, opens it, reads the
13:34headers, repackages it, and then makes
13:36another call to the server, essentially
13:38performing a redirection. For
13:40WebSockets, this doesn't work because
13:42it ends up breaking the WebSocket flow,
13:44which needs to be constant and
13:45continuous. So, layer 4 allows us to do
13:48this. It won't open anything, it won't
13:50do anything; it will just redirect to
13:52the server with the fewest connections.
13:54For example, this is already a load
13:56balancing strategy. It checks which
13:58server has the fewest open connections
14:00at the moment. It goes there and
14:02redirects, performing this routing. And
14:04that's why we use layer 4 and not layer
14:067. Cool, great. So, we have our layer 4
14:09load balancer here, redirecting to our
14:11servers. And now, instead of handling
14:14just 500,000 connections, we can handle
14:17500k, 1 million, 2 million, 2.5 million
14:19simultaneous connections on our servers
14:22. Wonderful. That's a whole lot. But
14:26there is something that happens here,
14:28which is exactly where the interviewer
14:30will want to know if you'll pass the
14:31interview or not, if you have the
14:33knowledge beyond just saying that
14:34WebSockets solve the real-time problem.
14:40And it's the following case: our user
14:42one is talking to our user two, but
14:44when routing, our load balancer decided
14:46to send them to server one and our user
14:48two to our server number four. So, how
14:52are they going to talk to each other?
14:56How will user two, when they send a
14:58message, know that server four needs to
15:00send a message over to server one to
15:01respond? If they were both connected to
15:05the same server, great, wonderful,
15:06solved. But what about when we have
15:08these multiple servers; how do servers
15:10communicate with each other? How do we
15:12solve this problem? So, to solve this
15:15problem, we are going to choose a
15:16strategy that many companies use. It's
15:19kind of a standard, but of course, it's
15:21not the only solution. We could use
15:24Rabbit, we could use Kafka, but many
15:26companies choose this strategy for its
15:28simplicity, as it solves our exact
15:30problem: the pub/sub strategy with
15:32Redis. Redis tackles this exact problem
15:37of communication between servers, and
15:39here is how it works. Basically, when
15:43our first user connects to the server,
15:45they subscribe to a Redis topic. That
15:48topic will be called user 2.1, for
15:50example, with the one being the user's
15:53ID. This Redis topic acts like a
15:55listener; the person is listening to
15:57that topic, and whenever someone
15:59publishes something to it, the topic
16:01receives that publication, that event,
16:03that message. And we will use this
16:06exact strategy to address this server
16:08communication problem we have. So, in
16:11the same way, user two goes to server
16:13four and subscribes to a topic with
16:16their ID. When our first user went
16:19there and listed all the conversations
16:20they had on the frontend, they clicked
16:22on the conversation with user two.
16:24Since they listed it beforehand, they
16:26already have access to the ID of user
16:28two they want to communicate with. So,
16:29they will load that ID into the
16:31conversation because they will need it
16:33on the backend. When they hit enter,
16:36they send the message from user one to
16:37our server. It will publish this
16:41message to the topic user 2.2, which is
16:43the user they want to communicate with.
16:47Since user two is subscribed to that
16:49topic with their ID, they will go there
16:51and receive the message from user one.
16:54Likewise, when they publish to user
16:56one's topic, because user one is
16:58subscribed, they will receive the
17:00message. That is how we maintain this
17:04connection between both users, how we
17:06facilitate this conversation between
17:08them, regardless of which server they
17:10land on; Redis acts as our hub, our
17:11broker for messages and events
17:13occurring based on topic subscriptions
17:15within it. And this doesn't just work
17:19for users; it works for groups too. For
17:21example, if we have a group with 10
17:23people and all 10 are subscribed to
17:25topic group 2.1.23, for instance,
17:27whenever someone sends a message to
17:29that topic, everyone subscribed will
17:31receive it. The servers will all update
17:34at the same time and send it to the
17:36frontend. So this works for a user, a
17:40group, or anything that is a topic in
17:42Redis, and if someone publishes to that
17:44topic, all subscribers will receive
17:46that message. Cente already solves this
17:49server issue, allowing for 10, 15, or
17:51even 20 servers. Redis will be our
17:54controller; it's what will route the
17:55messages to the servers that are
17:57subscribed to it. This is phenomenal
18:00because in most interviews, people stop
18:02here; they know how to use WebSockets,
18:04they know Server-Sent Events exist,
18:06they know the concepts, but they don't
18:08know what comes next. So, knowing that
18:11the Load Balancer needs to be layer 4
18:13for WebSocket connections, and
18:15understanding how it works on the
18:17server side—the second stage of
18:18communication, how servers talk to each
18:21other—is phenomenal. And there's a
18:25little question that always comes up in
18:26interviews when the subject is
18:28real-time chat updates, for example,
18:30which is: "What if the user is offline?
18:32How will they receive the messages?""
18:35Because if Redis publishes there, and
18:37someone publishes a message to Redis
18:39saying: 'Hi, how are you?'" And that
18:41person is not subscribed. That message
18:44is lost; there's no way to recover it.
18:46So, how do we solve the case for people
18:48who have their phones turned off? "For
18:50example?" The answer to that is
18:51actually very simple. There are other
18:54ways to do this, but I’m going to
18:56share with you one way, a strategy that
18:58is quite reasonable and works perfectly
19:00for our cases. So, we will have, for
19:03example, a table in our database for
19:05pending messages. Whenever we publish a
19:08message to Redis, we will also save
19:10that message in this table. So, if our
19:14user isn't online, they won't receive
19:16that message in real-time via the Redis
19:18subscription, but they will have this
19:20backup in that table. As soon as they
19:23reconnect to our application, they make
19:25a call to this table and check if there
19:26is any data in it. If there is, we grab
19:29everything in a package, send it all
19:31back to them, and then they can see all
19:33the messages that were pending for them
19:35. And we can also approach this type of
19:37strategy in two ways. Some people keep
19:41all these messages stored as a history
19:43in the database, but others prefer to
19:45keep it temporarily. For example, if
19:49I'm not mistaken, WhatsApp does this.
19:51He doesn't keep those messages saved in
19:53his database due to legal reasons. He
19:56doesn't want to store sensitive data on
19:57his end in case of a leak or anything
19:59like that. So, he leaves these messages
20:02temporarily, and as soon as you
20:04retrieve all messages after being
20:06offline, he deletes everything, ensures
20:08you have it all on your phone, performs
20:10the monthly backup, and so on; this way
20:12, he keeps his side clean, without
20:14messages containing sensitive data, and
20:16ensures you already have everything you
20:18need on your cell phone, for example.
20:21Or we could add a timestamp to these
20:23messages, for example, and say: "Look,
20:25I only received up to this last message
20:27. Give me everything that came after it
20:30while I was offline." We go there,
20:32perform this calculation, fetch all the
20:34messages, and return them to our user.
20:36We can do it in either of these two
20:38ways. And with that, we finish all the
20:40concepts and strategies for dealing
20:42with real-time updates. We talked about
20:45WebSockets, polling, and server-sent
20:47events, and we understood how the L4
20:49Load Balancer works and why it needs to
20:51be at that layer, specifically because
20:53of the TCP connection that WebSockets
20:55have, which requires constant tunneling
20:57. We understood the second part, how
21:00servers communicate with each other,
21:02and how we handle offline users. And
21:05here, just to be clear, server-sent
21:07events also work the same way. We can
21:10also use Redis Pub/Sub to facilitate
21:12this conversation when we have many
21:14servers communicating, when something
21:16happens on one server, but the user is
21:18connected to a different server to
21:20receive the event via SSE. So we also
21:23use Redis Pub/Sub, which will also work
21:26perfectly for these cases. And this way
21:29, we manage to address all the points
21:31and all the complexities we had in mind
21:32. And I am sure you will be much better
21:36prepared to answer interview questions
21:38about real-time updates. The main
21:41mistakes people make during interviews
21:43are exactly the ones we discussed. They
21:46don't know how to handle horizontal
21:48server scaling. They don't talk about
21:51or mention how this second part works,
21:53how servers communicate with each other
21:54, or what mechanism they will use to
21:56make that happen. They don't know how
21:59to handle it when a user is offline, or
22:01they simply freeze when the interviewer
22:03asks. It is also worth remembering that
22:06polling is not a bad strategy; it is a
22:08simple strategy for a simple problem.
22:10And sometimes that is exactly what the
22:11interviewer wants from you. You're not
22:13going to go around putting a bunch of
22:15web socket infrastructure into a system
22:17that has 100 active users. It doesn't
22:19even make sense. So the interviewer
22:22often wants to know if you understand
22:24the problem at hand, what is being
22:25required of you, which solution to
22:27implement for that case, and they
22:29evolve it gradually. So, okay, that's
22:31fine for 100 active users, but what if
22:34we now have 100,000 active users
22:36operating there daily? So it is
22:38progressive. Don't fall into the trap
22:41of using a super heavy architecture for
22:43a system that is super simple. And it's
22:46also super important to remember to
22:48mention: "Whenever we are working with
22:50Web Sockets, we use layer 4 load
22:52balancers, not layer 7." Extremely
22:54important, it will guarantee you extra
22:56points in the interview. I truly hope
23:00you learned something new in this video
23:02or that some concept was reinforced for
23:04you. So, please, leave a like here,
23:06leave a comment with any suggestions or
23:08any possible questions, and subscribe
23:10to the channel so you don't miss the
23:12next videos in the series. In the next
23:15one, we'll talk about how to deal with
23:17gigantic files, how we manage to upload
23:19a 200 GB file to YouTube or Google
23:21Drive, and how they handle such a
23:23colossal file size. That is exactly
23:26what we will discuss in the next video,
23:28tying up a concept we left open from
23:30the last video regarding pre-signed
23:32URLs. So subscribe, don't miss it, and
23:34I'll see you in a bit. M.

About this transcript

This page contains the full transcript of Websocket, SSE e Polling: Atualizações em tempo real para entrevistas (System Design #4) by Pedro Camaforte, generated from the public captions YouTube serves with the video. The transcript has 4,226 words across 639 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.