Software Engineer Interview Prep Podcast
Oct 3, 2026 · 28 min · 10 segments
Why does a chat message arrive instantly, but the web was never built for it? In this deep dive we unpack WebSockets: how engineers turned a request/response web into an open, two-way line, and what…
Because before this technology existed, developers just had to fake real-time communication.
They really did.
It was incredibly clunky.
The most primitive method was something called short polling.
And to understand why this is so painful, you shouldn't even think about the Internet.
Think of like a retail store.
Oh, that's a good way to look at it.
Right.
Like short polling is basically like a kid in the backseat or, you know, constantly calling a busy store clerk every five seconds to ask, hey, did my package arrive yet?
And that analogy hits the nail on the head because the clerk's answer is almost always going to be no check back later.
Right.
Stop calling me.
Exactly.
And when you apply that to Internet architecture, you start to see why this strategy just violently breaks down at scale.
I mean, the source material outlines the math here and it is staggering.
Yeah.
Walk us through that math.
So imagine an application with one million active clients.
If every single one of those clients is using short polling to ask the server for updates every five seconds, well, the math gets terrifying very quickly.
Right, because five seconds, you know, it doesn't feel aggressive to a human, but for a server, that's an avalanche.
It results in 200,000 individual requests hitting your infrastructure every single second.
Wow.
And the vast majority of those requests are completely empty.
The server has to, you know, allocate CPU cycles, open a temporary connection, parse hundreds of bytes of standard HTTP headers.
Like the cookies and user agent strings and all that.
Because before this technology existed, developers just had to fake real-time communication.
They really did.
It was incredibly clunky.
The most primitive method was something called short polling.
And to understand why this is so painful, you shouldn't even think about the Internet.
Think of like a retail store.
Oh, that's a good way to look at it.
Right.
Like short polling is basically like a kid in the backseat or, you know, constantly calling a busy store clerk every five seconds to ask, hey, did my package arrive yet?
And that analogy hits the nail on the head because the clerk's answer is almost always going to be no check back later.
Right.
Stop calling me.
Exactly.
And when you apply that to Internet architecture, you start to see why this strategy just violently breaks down at scale.
I mean, the source material outlines the math here and it is staggering.
Yeah.
Walk us through that math.
So imagine an application with one million active clients.
If every single one of those clients is using short polling to ask the server for updates every five seconds, well, the math gets terrifying very quickly.
Right, because five seconds, you know, it doesn't feel aggressive to a human, but for a server, that's an avalanche.
It results in 200,000 individual requests hitting your infrastructure every single second.
Wow.
And the vast majority of those requests are completely empty.
The server has to, you know, allocate CPU cycles, open a temporary connection, parse hundreds of bytes of standard HTTP headers.
Like the cookies and user agent strings and all that.
The rest of this transcript — segmented and speaker-labeled, so you land on the exact moment something was said
Search every transcript — by keyword, by phrase, or by meaning, across every show Radar indexes
Trends — what is surging across podcasts, measured against its own baseline
Alerts — when a name you follow appears in a newly indexed episode
No account is needed to search Radar.