DEV Community: Anik Sikder

Multiplexing vs Connection Pooling: Why HTTP/2 Changed Everything

Anik Sikder — Sat, 01 Aug 2026 14:47:07 +0000

In the previous articles of this series, we explored a recurring theme:

Every generation of web infrastructure solved one bottleneck only to expose another.

HTTP/1.0 suffered from connection setup overhead.
HTTP/1.1 introduced persistent connections.
Then browsers started requesting hundreds of assets.
Persistent connections helped, but a new problem emerged: Head-of-Line Blocking.
To work around it, browsers began opening multiple TCP connections.

That workaround became known as Connection Pooling.

For years, Connection Pooling was the hidden engine powering the modern web.

Then HTTP/2 arrived and asked a dangerous question:

What if we stopped opening more connections and instead made a single connection smarter?

That idea became Multiplexing.

This article explores why that shift fundamentally changed web architecture.

The Problem Nobody Intended to Create

Imagine it's 2012.

A user opens your e-commerce homepage.

The browser needs:

HTML
CSS files
JavaScript bundles
Product images
Recommendation widgets
Analytics scripts
Tracking pixels
Fonts

A single page can easily require:

100+ requests

Yet HTTP/1.1 processes requests sequentially on a connection.

Connection 1

Request A
Response A

Request B
Response B

Request C
Response C

The browser quickly discovers something painful:

If Request A is slow,

everything behind it waits.

This becomes Head-of-Line Blocking.

The First Large-Scale Workaround

Browser vendors couldn't change HTTP overnight.

So they found another solution.

Open more TCP connections.

Instead of:

1 Connection
100 Requests

Browsers evolved toward:

Connection 1
Connection 2
Connection 3
Connection 4
Connection 5
Connection 6

Each connection handles separate requests.

Example:

Connection 1 -> CSS
Connection 2 -> JS
Connection 3 -> Image
Connection 4 -> Image
Connection 5 -> Font
Connection 6 -> API

Now multiple requests can progress simultaneously.

This dramatically improved page load performance.

The strategy became known as:

Connection Pooling

What Exactly Is Connection Pooling?

Connection Pooling means maintaining a collection of reusable connections instead of creating a new connection for every request.

Instead of:

Request
Create TCP
TLS
Send
Close

for every operation,

the browser maintains a pool:

Pool

Connection 1
Connection 2
Connection 3
Connection 4
Connection 5
Connection 6

Incoming requests are assigned to available connections.

Request A -> Connection 1
Request B -> Connection 2
Request C -> Connection 3

This reduces:

TCP handshake cost
TLS handshake cost
Connection setup latency

For years, this approach worked surprisingly well.

But it introduced new operational problems.

Postmortem: The Scaling Problem Nobody Talks About

Imagine a popular online marketplace.

Traffic:

500,000 active users

Browser behavior:

6 connections per origin

Potential active connections:

3,000,000 TCP connections

Now consider the infrastructure.

Every connection consumes:

Memory
Kernel resources
TCP buffers
TLS state

Suddenly the architecture team realizes:

We are spending more resources managing connections than delivering content.

The system is technically healthy.

Yet servers remain under pressure.

Not because requests are expensive.

Because connections are expensive.

The Hidden Cost of Connection Pooling

Most performance discussions focus on requests.

Infrastructure teams focus on connections.

Each TCP connection carries overhead.

Example:

Client
   │
TCP State
TLS State
Receive Buffer
Send Buffer
Kernel Metadata
   │
Server

Multiply this by millions of active connections.

The resource footprint becomes enormous.

This is why large-scale systems obsess over connection efficiency.

Another Problem: Congestion Control

Each TCP connection behaves independently.

Imagine six connections:

Connection 1
Connection 2
Connection 3
Connection 4
Connection 5
Connection 6

Each has:

Its own congestion window
Its own retransmissions
Its own packet loss handling

The network now sees six competing traffic flows from the same browser.

This is inefficient.

The browser is essentially pretending to be six different clients.

The protocol wasn't designed for this.

It was a workaround.

The HTTP/2 Idea

Engineers looked at the situation and asked:

Why are we creating six connections just to achieve parallelism?

What if one connection could handle many requests simultaneously?

Instead of:

Connection 1
Connection 2
Connection 3
Connection 4
Connection 5
Connection 6

Use:

Connection 1
 ├─ Request A
 ├─ Request B
 ├─ Request C
 ├─ Request D
 ├─ Request E

One connection.

Many independent conversations.

That idea became:

Multiplexing

Understanding Multiplexing

In HTTP/2, requests no longer own connections.

They own streams.

TCP Connection
     │
 ┌───┼───────────┐
 │   │           │
Stream 1
Stream 2
Stream 3
Stream 4
Stream 5

Each request receives its own stream.

Example:

Stream 1 -> CSS
Stream 2 -> JS
Stream 3 -> Image
Stream 4 -> API
Stream 5 -> Font

All streams share the same TCP connection.

The Magic: Interleaving

HTTP/1.1:

Request A
Response A
Request B
Response B

HTTP/2:

A1
B1
C1
A2
B2
C2
A3
B3
C3

Data from different streams becomes interleaved.

The connection continuously carries frames from multiple requests.

No request owns the connection.

The connection belongs to everyone.

This is true multiplexing.

Real Example: Product Page Load

Suppose a product page requires:

HTML
5 CSS files
10 JS files
20 images
2 APIs

HTTP/1.1:

Browser

Connection 1
Connection 2
Connection 3
Connection 4
Connection 5
Connection 6

Requests are distributed across the pool.

Some connections become idle.

Others become overloaded.

Load balancing is imperfect.

HTTP/2:

Single Connection

Stream 1
Stream 2
Stream 3
...
Stream 38

All resources travel simultaneously through the same connection.

The browser no longer plays connection management games.

The protocol handles concurrency natively.

The Business Impact

Most executives never hear the term Multiplexing.

They only see metrics.

Before:

Page Load Time: 4.2s
Bounce Rate: Higher
Conversion Rate: Lower

After optimization:

Page Load Time: 2.8s
Bounce Rate: Lower
Conversion Rate: Higher

Users do not care whether the improvement came from:

TCP tuning
Multiplexing
Compression
Prioritization

They only experience speed.

For many businesses:

Faster Pages
=
More Revenue

The Developer Impact

Before HTTP/2, frontend engineers developed strange habits.

Examples:

CSS Sprites

Combining many images into one file.

icon1.png
icon2.png
icon3.png

became

sprites.png

JavaScript Bundling

20 JS Files

became

app.bundle.js

Domain Sharding

img1.example.com
img2.example.com
img3.example.com

This trick forced browsers to create more connection pools.

These techniques existed largely because HTTP/1.1 had connection limitations.

Multiplexing removed many of those constraints.

The Postmortem Nobody Expected

Many teams upgraded to HTTP/2 expecting:

6 Connections
↓
1 Connection
↓
6x Faster

Reality was more complicated.

A surprising issue emerged.

HTTP/2 still runs on:

TCP

And TCP still suffers from packet loss.

If a packet is lost:

TCP waits
TCP retransmits
TCP recovers

All streams share that same connection.

Meaning:

Stream 1 waits
Stream 2 waits
Stream 3 waits
Stream 4 waits

This became a new form of Head-of-Line Blocking.

Not at the HTTP layer.

At the TCP layer.

HTTP/2 solved one bottleneck while exposing another.

Exactly the same pattern we've seen throughout internet history.

Connection Pooling vs Multiplexing

Connection Pooling:

Many Connections
One Request Flow Per Connection
Parallelism Through More Connections

Connection 1 -> Request A
Connection 2 -> Request B
Connection 3 -> Request C

Multiplexing:

One Connection
Many Streams
Parallelism Inside Connection

Connection 1
 ├─ Stream A
 ├─ Stream B
 ├─ Stream C

Connection Pooling optimizes:

Connection Reuse

Multiplexing optimizes:

Connection Utilization

Connection Pooling says:

Let's create several reusable highways.

Multiplexing says:

Let's build one intelligent highway with many lanes.

The Bigger Lesson

Connection Pooling was never the final destination.

It was an engineering workaround.

Multiplexing was the architectural correction.

The web spent years fighting the limitations of HTTP/1.1 by opening more and more connections.

HTTP/2 changed the question entirely.

Instead of asking:

"How many connections do we need?"

Engineers began asking:

"How much work can one connection perform?"

That shift seems small.

But it fundamentally changed how browsers, servers, load balancers, CDNs, and modern applications communicate.

And it paved the road for the next evolution of the web:

HTTP/3 and QUIC, where engineers finally attempted to eliminate TCP-level Head-of-Line Blocking itself.

Publish-Subscribe: How Modern Systems Scale Without Becoming a Monolith

Anik Sikder — Thu, 30 Jul 2026 17:53:36 +0000

When an online order is placed, the customer sees a simple message:

"Your order has been confirmed."

Behind that message, however, an entire chain of events begins.

The inventory must be updated.

The payment must be recorded.

The customer should receive an email.

Analytics dashboards need updating.

Fraud detection systems may need to run.

Loyalty points might need to be awarded.

Shipping labels may need to be generated.

In small systems, developers often connect these actions directly.

Order Service
 ├── Update Inventory
 ├── Send Email
 ├── Update Analytics
 ├── Create Invoice
 └── Start Shipping

At first, this seems perfectly reasonable.

Then the business grows.

And everything starts breaking.

The Architecture That Works Until It Doesn't

Imagine an e-commerce platform processing 50 orders per day.

A customer places an order.

The Order Service directly calls:

Inventory Service
Email Service
Analytics Service
Billing Service
Shipping Service

Everything succeeds.

Everyone is happy.

The architecture appears simple.

The problem is that simplicity is deceptive.

The Order Service now depends on every downstream service.

If any one of them is slow, the entire workflow becomes slow.

If any one of them fails, the customer experience can fail.

The more business capabilities added, the larger this dependency chain becomes.

Over time the Order Service quietly transforms into the center of the entire company.

Every new feature adds another dependency.

Every new dependency increases risk.

A Real Failure Scenario

Consider this order workflow:

Customer
    ↓
Order Service
    ↓
Inventory Service
    ↓
Email Service
    ↓
Analytics Service

One day the Email Service experiences an outage.

Now what happens?

Many systems accidentally end up with behavior like this:

create_order()

reserve_inventory()

send_confirmation_email()

update_analytics()

Email fails.

The transaction stops.

Analytics never updates.

The customer may not even receive order confirmation.

A problem in one subsystem cascades across the platform.

This is known as tight coupling.

The services are technically separate.

Operationally, they are not.

The Postmortem Nobody Wants to Write

A common production incident looks something like this:

What happened?

A third-party email provider experienced elevated latency.

Impact

Order creation response times increased from:

200ms

8-15 seconds

Business Impact

Customers abandoned checkout.

Conversion rates dropped.

Support tickets increased.

Revenue was affected.

Root Cause

The Order Service was waiting for Email Service completion before responding.

Architectural Problem

The platform treated a non-critical operation as a critical dependency.

Notice something important.

The email system wasn't actually required to create the order.

The order should have succeeded regardless.

The architecture created the outage.

Not the email provider.

Enter Publish-Subscribe

Instead of directly calling every service, the Order Service publishes an event.

Order Service
      ↓
Order Created Event
      ↓
Message Broker
      ↓
Inventory
Email
Analytics
Billing
Shipping

Now the Order Service only has one responsibility:

Create Order
Publish Event
Done

It no longer cares who needs the information.

It simply announces:

Order Created

Anyone interested can react.

This changes everything.

Thinking in Events Instead of Calls

Traditional systems think:

Do this.
Then do that.
Then do another thing.

Event-driven systems think:

Something happened.
Whoever cares can respond.

That shift sounds small.

Architecturally, it is enormous.

The producer no longer knows:

Who consumes the event
How many consumers exist
When consumers process it
What consumers do with it

The producer simply publishes facts.

The Message Broker Becomes the Traffic Controller

A message broker sits between producers and consumers.

Examples include:

Apache Kafka
RabbitMQ
Amazon SNS
Amazon SQS

The broker receives events and distributes them to interested systems.

Publisher
    ↓
Broker
 ├── Inventory
 ├── Email
 ├── Billing
 ├── Analytics
 └── Fraud Detection

Services no longer communicate directly.

The broker acts as the central nervous system.

Why Business Leaders Should Care

Most architectural decisions eventually become business decisions.

Publish-Subscribe creates advantages that executives feel directly.

Faster Feature Delivery

Imagine marketing wants a loyalty points system.

In a tightly coupled architecture:

Modify Order Service
Retest Order Service
Redeploy Order Service
Risk Order Service

In Pub/Sub:

Create Loyalty Consumer
Subscribe to Order Created
Deploy Independently

The order system remains untouched.

New business capabilities can be added safely.

Reduced Revenue Risk

If Analytics fails:

Orders continue.
Payments continue.
Customers continue.

Only analytics is affected.

The failure is isolated.

This dramatically reduces blast radius.

Better Organizational Scaling

As companies grow:

Payments Team
Inventory Team
Data Team
Growth Team
Customer Team

Each team can consume events independently.

Teams become less dependent on one another.

This increases development velocity.

Why Developers Love Event-Driven Systems

Developers eventually discover a painful truth:

The hardest part of scaling is not traffic.

It's dependencies.

Pub/Sub removes many of them.

Loose Coupling

Without Pub/Sub:

Order Service
    ↓
Inventory
    ↓
Email
    ↓
Analytics

With Pub/Sub:

Order Service
      ↓
Broker
      ↓
Consumers

The producer has one dependency.

Instead of ten.

Independent Deployments

A team can deploy:

Recommendation Engine
Fraud Detection
Customer Segmentation

without touching the ordering system.

This dramatically reduces deployment risk.

Better Resilience

Suppose Billing Service crashes.

The broker stores events.

When Billing returns:

Order Created Event #1001
Order Created Event #1002
Order Created Event #1003

can still be processed.

The platform recovers automatically.

But Publish-Subscribe Creates New Problems

Many architecture articles stop at benefits.

Production systems do not.

Every architectural gain introduces tradeoffs.

Problem #1: Eventual Consistency

In synchronous systems:

Order Created
Inventory Updated
Response Returned

Everything happens immediately.

In Pub/Sub:

Order Created
Response Returned

Inventory Updated Later

There is now a time gap.

Systems may temporarily disagree.

This is called:

Eventual Consistency

One of the most misunderstood realities of distributed systems.

Problem #2: Duplicate Events

Networks fail.

Retries happen.

Consumers crash.

The same event may arrive twice.

Order Created #123
Order Created #123

Consumers must be idempotent.

Otherwise:

Inventory reduced twice
Customer charged twice

Production incidents happen.

Problem #3: Observability Becomes Hard

In monolithic workflows:

Request → Response

Easy to trace.

In event-driven systems:

Order Created
    ↓
Inventory Updated
    ↓
Billing Created
    ↓
Email Sent
    ↓
Analytics Updated

A single customer action can generate dozens of events.

Tracking failures becomes significantly harder.

This is why mature organizations invest heavily in:

Distributed tracing
Correlation IDs
Event monitoring
Audit logs

How Large Platforms Actually Think

The most successful architectures do not ask:

"Which service should call which?"

Instead they ask:

"What business events exist?"

Examples:

Order Created
Payment Authorized
Shipment Created
Invoice Generated
User Registered
Subscription Renewed

These events become the language of the business.

Systems are then built around reacting to those events.

The result is an architecture that grows with the company instead of fighting it.

The Real Lesson

Publish-Subscribe is not primarily about messaging.

It is about organizational scalability.

It allows systems to evolve without every team depending on every other team.

It reduces blast radius.

It improves resilience.

It accelerates feature delivery.

But it also introduces complexity, eventual consistency, and operational challenges that teams must be prepared to handle.

The companies that scale successfully are rarely the ones with the most services.

They are the ones with the clearest events.

Because once systems start speaking in events instead of direct dependencies, growth becomes far easier to sustain.

Key Takeaway

A mature architecture doesn't ask:

"Who should I call next?"

It asks:

"What happened?"

That single shift from commands to events is one of the biggest architectural transitions in modern software systems.

Server-Sent Events (SSE): When the Web Learned to Listen

Anik Sikder — Mon, 27 Jul 2026 16:58:10 +0000

For years, the web operated on a simple principle:

Browser asks.
Server answers.
Connection closes.

This model worked perfectly when websites were mostly documents.

A user opened a page.

The browser requested data.

The server responded.

Everyone moved on.

But then the internet changed.

Businesses wanted live stock prices.

Operations teams wanted real-time monitoring dashboards.

Support agents wanted instant notifications.

Users expected applications to update the moment something happened.

The old request-response model suddenly felt too slow.

The challenge wasn't that servers couldn't produce updates quickly.

The challenge was getting those updates to users immediately.

And that led engineers down a fascinating path:

Request-Response
        ↓
Polling
        ↓
Long Polling
        ↓
Server-Sent Events (SSE)

SSE wasn't just another protocol.

It was the web's attempt to become truly real-time while still staying within the familiar world of HTTP.

The Business Problem Nobody Could Ignore

Imagine you're running a stock trading platform.

At market open, prices can change thousands of times every second.

Your users expect something like this:

AAPL  $202.15
MSFT  $541.22
NVDA  $193.47

And when prices change:

AAPL  $202.31
MSFT  $541.40
NVDA  $193.61

The update should appear instantly.

Not five seconds later.

Not after a page refresh.

Not after clicking a button.

Immediately.

From a business perspective, this sounds simple:

"Show customers the latest information as soon as it changes."

From a system design perspective, it's much harder.

How does the browser know when something changes?

The First Attempt: Polling

The most obvious solution was polling.

The browser repeatedly asked:

Any updates?

Every few seconds.

Browser
    │
    ├── Request
    ├── Request
    ├── Request
    ├── Request
    └── Request

Most of the time the server replied:

Nothing changed.

Imagine 100,000 users checking every second.

Even when no new information existed:

100,000 Requests
          ↓
100,000 Responses
          ↓
No Useful Data

The system was working hard to accomplish almost nothing.

The architecture scaled poorly.

Infrastructure costs increased.

Servers processed millions of unnecessary requests.

Engineers needed something better.

The Second Attempt: Long Polling

Long Polling improved efficiency.

Instead of responding immediately, the server waited.

Browser Request
       ↓
Server Waits
       ↓
Event Happens
       ↓
Server Responds

If a stock price changed, the server responded instantly.

If nothing happened, the connection stayed open.

This dramatically reduced useless requests.

But Long Polling still had a problem.

After every response:

Response Received
        ↓
Create New Request
        ↓
Wait Again

The cycle never truly disappeared.

The browser was still repeatedly initiating communication.

Just less frequently.

The Simple Question That Changed Everything

Eventually engineers asked:

Why is the browser constantly asking for updates?

If the server already knows when something changes, why not let the server send the update directly?

That question led to Server-Sent Events.

What Is Server-Sent Events (SSE)?

Server-Sent Events allow a browser to open a single HTTP connection and keep it alive.

Instead of repeatedly asking for information, the browser simply listens.

Browser
     │
     │ Open Connection
     ▼
Server
     │
     ├── Event
     ├── Event
     ├── Event
     └── Event

The server pushes updates whenever something happens.

No polling loop.

No repeated requests.

No constant reconnecting.

The browser becomes a subscriber.

The server becomes a publisher.

A Different Way of Thinking

Polling asks:

Did anything happen?
Did anything happen?
Did anything happen?
Did anything happen?

SSE says:

Tell me when something happens.

That sounds like a small difference.

Architecturally, it's huge.

Inside a Real SSE Connection

From the browser's perspective, creating an SSE connection is surprisingly simple.

const events = new EventSource("/events");

The browser sends a normal HTTP request.

The server responds with a special content type:

text/event-stream

But unlike a normal HTTP response, the server doesn't close the connection.

Instead, it keeps streaming data.

data: New Order Created

data: Payment Received

data: Shipment Dispatched

The browser receives each event immediately.

The connection remains open.

The stream continues.

Real System Example: E-Commerce Operations Dashboard

Consider a large e-commerce company.

The operations team monitors incoming orders in real time.

Without SSE:

Dashboard
    ↓
Poll Every 5 Seconds
    ↓
Check For New Orders

A customer places an order.

The operations team might not see it for several seconds.

With SSE:

Customer Places Order
          ↓
Order Service
          ↓
Event Bus
          ↓
Notification Service
          ↓
SSE Gateway
          ↓
Dashboard

The moment the order is created:

New Order Received

appears on the dashboard.

No refresh required.

No polling required.

To the user, the system feels alive.

Real System Example: Monitoring Platforms

Modern monitoring tools often display:

CPU utilization
Memory usage
Error rates
Request latency
Active users

Imagine a platform monitoring thousands of servers.

Every metric changes continuously.

Polling every few seconds creates unnecessary traffic.

Instead:

Monitoring Agent
  ↓
Metrics Service
  ↓
Event Stream
  ↓
SSE
  ↓
Dashboard

As metrics change, updates appear instantly.

Operations teams gain near real-time visibility into system health.

Real System Example: AI Response Streaming

Today, one of the most recognizable uses of SSE is AI.

When you ask ChatGPT a question, the model doesn't generate an entire response instantly.

It generates tokens one at a time.

Without streaming:

User Question
       ↓
Wait 10 Seconds
       ↓
Entire Answer Appears

From the user's perspective:

System feels slow.

With SSE:

User Question
       ↓
Wait 1 Second
       ↓
Words Begin Appearing
       ↓
Response Continues Streaming

The total generation time may still be ten seconds.

But the experience feels dramatically faster.

This reveals an important system design principle:

Users experience latency differently than systems measure latency.

A ten-second wait feels frustrating.

A ten-second stream feels interactive.

SSE helps bridge that gap.

This is one reason AI products feel conversational rather than delayed.

Why Product Teams Love SSE

From a product perspective, SSE improves perceived responsiveness.

Users don't care how elegant your architecture is.

They care about what they see.

Compare:

Click
     ↓
Wait
     ↓
Wait
     ↓
Wait
     ↓
Response

Versus:

Click
     ↓
Response Starts
     ↓
More Content
     ↓
More Content

The second experience feels dramatically faster even if total processing time is identical.

That translates directly into:

Better engagement
Better user satisfaction
Higher retention
More trust in the product

Why Developers Love SSE

One reason SSE became popular is that it works with existing HTTP infrastructure.

There is no entirely new protocol to learn.

Browser
   ↓
HTTP
   ↓
Load Balancer
   ↓
Reverse Proxy
   ↓
Application Server

Everything already understands HTTP.

This makes adoption much easier.

Developers also benefit from automatic reconnection.

If a connection drops:

Connection Lost
        ↓
Browser Detects Failure
        ↓
Automatic Reconnect

The browser handles much of the recovery logic automatically.

Less code.

Less complexity.

Fewer edge cases.

Why Architects Choose SSE

A common question is:

Why not just use WebSockets?

The answer depends on communication patterns.

Consider stock prices:

Market
   ↓
User

Or monitoring dashboards:

Server
   ↓
Dashboard

Or AI response streaming:

Model
   ↓
Browser

In all of these systems:

Server talks constantly.
Client rarely talks.

SSE fits naturally.

WebSockets support two-way communication:

Client ↔ Server

But many systems don't need that capability.

Using WebSockets in these situations can introduce complexity without delivering meaningful benefits.

One of the most important lessons in architecture is:

The best solution is not the most powerful one. It's the simplest one that satisfies the requirements.

For many one-way streaming workloads, SSE is exactly that solution.

The Hidden Challenge

Every architectural improvement introduces a new bottleneck.

Polling creates too many requests.

SSE solves that problem.

But it introduces another.

Persistent connections.

Imagine:

500,000 Active Users

Polling might create:

Millions of Requests Per Minute

SSE creates:

500,000 Open Connections

The request problem improves.

The connection management problem appears.

Infrastructure teams now worry about:

Memory consumption
File descriptor limits
Load balancer behavior
Proxy timeouts
Reconnection storms
Horizontal scaling

From an operations perspective:

Fewer Requests
≠
Less Work

The workload simply shifts.

Where SSE Starts To Break Down

SSE is excellent for one-way communication.

But some systems require continuous communication in both directions.

Examples include:

Chat applications
Multiplayer games
Collaborative editors
Trading platforms
Video conferencing systems

These applications need:

Client ↔ Server

communication.

SSE only provides:

Server → Client

At that point, WebSockets usually become the better architectural choice.

What SSE Really Changed

Server-Sent Events didn't introduce a revolutionary new protocol.

Its impact came from a much simpler idea:

Stop asking repeatedly.

Start listening continuously.

That shift helped transform the web from a collection of documents into a platform for real-time experiences.

Stock prices could update instantly.

Dashboards could refresh automatically.

Notifications could arrive the moment events occurred.

AI systems could stream responses as they were generated.

The technology itself is relatively simple.

The effect on user experience is enormous.

And that is often the hallmark of great system design:

A small architectural change that fundamentally improves how users experience a system.

The Evolution Continues

The web's journey toward real-time communication didn't stop with SSE.

Request-Response
   ↓
Polling
   ↓
Long Polling
   ↓
Server-Sent Events (SSE)
   ↓
WebSockets

SSE taught the web how to stream information.

WebSockets would teach the web how to have a conversation.

And that's where the next chapter begins.

Long Polling : The First Time the Web Tried to Feel Alive

Anik Sikder — Sat, 25 Jul 2026 17:22:07 +0000

In the previous article, we explored traditional polling.

At first glance, polling seemed like a reasonable solution.

A browser simply asked the server:

"Anything new?"

If nothing changed:

{
  "updates": []
}

The browser waited a few seconds and asked again.

Simple.

Predictable.

Easy to implement.

For small systems, it worked perfectly.

But then users changed.

And suddenly, polling became a business problem.

The Incident Nobody Talks About

Imagine it's 2008.

You're part of an engineering team building a rapidly growing social platform.

Your CEO walks into the room and says:

"Users are complaining that messages feel slow."

The database is healthy.

The servers are healthy.

The network is healthy.

Yet users are unhappy.

Why?

Because technology was measuring milliseconds.

Users were measuring feelings.

To them:

Message Sent
       │
       ▼
Nothing Happens
       │
       ▼
3 Seconds Later...
       │
       ▼
Message Appears

The application felt broken.

Not because it was slow.

Because it wasn't instant.

And expectations were changing.

The Product Team's Suggestion

The product manager proposes a simple solution.

"Let's poll more often."

Instead of every 10 seconds:

Poll Every 1 Second

Everyone nods.

Problem solved.

Or so they think.

Three weeks later, infrastructure costs spike.

Monitoring dashboards light up.

Operations teams start asking questions.

The Postmortem

After investigation, engineers discover something surprising.

The system isn't struggling because users are sending messages.

The system is struggling because users are asking if there are messages.

Imagine:

200,000 Users

Each user polls every second.

200,000 Requests / Second

Now imagine only 2% of those requests actually contain new information.

That means:

196,000 Requests

exist solely to hear:

"No updates."

Every second.

All day.

Every day.

The servers are spending most of their time answering questions nobody needed to ask.

Looking at the Problem Like an Architect

A junior developer might see:

"Too many requests."

A system architect sees:

"The communication model is wrong."

The real issue wasn't server performance.

The issue was this:

Client
   │
   ▼
Keeps Asking

Even when the server already knows nothing has changed.

The architecture was forcing unnecessary conversations.

A Different Idea

One engineer proposes something unusual.

Instead of:

Client:
Anything new?

Server:
No.

Client:
Anything new?

Server:
No.

What if the conversation became:

Client:
Tell me when something changes.

Server:
Okay. I'll wait.

And that's exactly what Long Polling became.

Long Polling Explained Like a Recruiter

Imagine you're hiring for a company.

Traditional polling looks like this:

Recruiter:
Any new applicants?

System:
No.

Recruiter:
Any new applicants?

System:
No.

Recruiter:
Any new applicants?

System:
No.

Long Polling changes the workflow.

Recruiter:
Call me when somebody applies.

System:
Understood.

Hours later:

New Applicant Submitted
         │
         ▼
Phone Rings

The recruiter isn't constantly checking.

The system notifies them only when something important happens.

That is Long Polling.

What Actually Happens Under the Hood

Let's say a user opens a chat application.

The browser sends:

GET /messages

Normally the server would immediately respond.

With Long Polling:

Request Arrives
       │
       ▼
Server Checks For Updates
       │
       ▼
No Updates Found
       │
       ▼
Keep Connection Open

Now the server waits.

Maybe 5 seconds.

Maybe 20 seconds.

Maybe 60 seconds.

Suddenly:

New Message Arrives

The server immediately responds.

{
  "message": "Hello!"
}

The browser receives the message.

Then instantly creates another waiting request.

Request
  │
Wait
  │
Response
  │
Reconnect
  │
Wait Again

To the user:

It feels instantaneous.

To the infrastructure:

It's still HTTP.

Just used differently.

Why Business Leaders Loved It

From a buyer's perspective, Long Polling created something valuable:

Faster Customer Support

Without Long Polling:

Customer Sends Message
       │
       ▼
Agent Sees It 10 Seconds Later

With Long Polling:

Customer Sends Message
       │
       ▼
Agent Sees It Almost Immediately

Response times improve.

Customer satisfaction improves.

Support metrics improve.

Revenue often improves.

Nobody buying the software cares about Long Polling.

They care that customers stop complaining.

Why Developers Loved It

Because it solved a real problem without requiring a new protocol.

Developers already had:

HTTP
Load Balancers
Reverse Proxies
Application Servers

No major infrastructure changes were needed.

Most teams could implement Long Polling with existing technology.

That made adoption relatively easy.

Why Operations Teams Hated It

Because Long Polling quietly moved pressure somewhere else.

Traditional polling creates:

Many Requests
Short Connections

Long Polling creates:

Fewer Requests
Long-Lived Connections

At first this sounds better.

Until your system reaches:

500,000 Active Users

Now you have:

500,000 Open Connections

waiting simultaneously.

The CPU usage might decrease.

But memory usage increases.

Connection tracking increases.

Load balancer complexity increases.

Timeout management becomes critical.

The bottleneck simply moved.

The Scaling Wall

Around this point, many companies hit a new challenge.

Imagine a global chat application.

1 Million Connected Users

Every user has:

One Waiting Request

Now the infrastructure must remember:

Who is connected
Which request belongs to whom
How long they've been waiting
When to timeout
When to reconnect

The system starts behaving less like a website.

And more like a real-time communication platform.

That distinction becomes important.

Because HTTP was never designed for this.

The Architect's Lesson

Long Polling teaches one of the most important lessons in software architecture.

The first solution that works is rarely the final solution.

The evolution looked like this:

Polling
    │
    ▼
Too Much Waste
    │
    ▼
Long Polling
    │
    ▼
Too Many Open Connections
    │
    ▼
Search For Something Better

Long Polling wasn't the destination.

It was the bridge.

A brilliant compromise between:

User expectations
Existing browser capabilities
Available infrastructure
Engineering constraints

For nearly a decade, some of the largest systems on the internet relied on that compromise.

The Question That Changed Everything

Eventually engineers started asking a different question.

Not:

"How can the client ask more efficiently?"

But:

"Why is the client asking at all?"

What if the connection stayed open permanently?

What if the server could speak first?

What if communication flowed both directions?

That question led to one of the biggest shifts in modern web architecture:

WebSockets.

And that's where our story goes next.

Polling: When "Simple" Starts Sending Millions of Requests

Anik Sikder — Fri, 24 Jul 2026 15:40:20 +0000

Imagine you're building a SaaS platform.

Nothing fancy.

Just a notification bell in the top-right corner.

When someone receives a new message, completes a task, or gets assigned work, the bell should update.

Seems simple, right?

A developer might propose:

Every 5 seconds:

GET /notifications

Done.

Feature shipped.

Customers happy.

Everyone goes home.

For a while.

The Architecture Looks Innocent

With 10 users online, the system behaves exactly as expected.

10 Users
   ↓
GET /notifications
Every 5 seconds

Nobody notices a problem.

The database barely feels the load.

The servers are mostly idle.

The feature appears successful.

This is where many architectural mistakes begin.

Not because the solution is wrong.

But because it works.

Success Changes the Equation

Six months later, your product gains traction.

Now you have:

5,000 active users

The code hasn't changed.

The infrastructure hasn't changed.

The polling interval is still:

Every 5 seconds

But the system is now processing:

5,000 × 12 requests/minute

= 60,000 requests per minute

That's:

3.6 million requests per hour

For a notification system.

Not file uploads.

Not payments.

Not business-critical operations.

Just checking whether something changed.

The Hidden Question

Here's the question experienced engineers ask:

How many of those requests actually matter?

Let's assume only 5% of users receive a notification during a given minute.

That means 95% of requests exist only to discover:

{
  "notifications": []
}

The system is spending CPU, memory, network bandwidth, and database resources simply confirming that nothing happened.

From a business perspective, that's interesting.

Because the company isn't paying for useful work.

It's paying for uncertainty.

Why Companies Still Choose Polling

At this point, many articles declare:

"Polling is bad."

That's the wrong conclusion.

Companies don't buy architectures.

Companies buy outcomes.

Polling remains popular because it optimizes for something businesses care deeply about:

Speed of Delivery

A startup founder rarely asks:

"Is this the most elegant distributed systems solution?"

They ask:

"Can we launch this feature next week?"

Polling is attractive because:

Easy to implement
Easy to debug
Easy to maintain
Works through almost every network and firewall
Requires minimal infrastructure

In other words:

Higher operational cost
↓
Lower development cost

And early-stage companies often prefer that tradeoff.

The Real Architectural Tradeoff

Junior developers often think:

Polling vs WebSockets

Senior engineers think:

Development Cost
vs
Infrastructure Cost
vs
User Experience
vs
Future Scale

Those are completely different conversations.

Every architecture decision is a business decision wearing a technical disguise.

When Polling Becomes Expensive

Imagine your SaaS platform grows to:

100,000 active users

Still polling every 5 seconds.

Now the system receives:

20,000 requests every second

Suddenly:

More application servers
Larger database clusters
Higher cloud bills
More monitoring
More operational complexity

The notification feature itself hasn't become more valuable.

The architecture simply became more expensive.

This is one of the easiest ways successful products accidentally create technical debt.

Not through bad code.

Through successful growth.

The Most Important Lesson

Polling is not a communication pattern.

Polling is an optimization choice.

You're optimizing for:

Simplicity Today

while accepting:

Higher Costs Tomorrow

Sometimes that's exactly the right decision.

Sometimes it's not.

The best engineers aren't the ones who know the newest technologies.

They're the ones who understand the tradeoffs.

And Polling is one of the simplest examples of that principle.

Push vs Pull: A Decision About Where Complexity Lives

Anik Sikder — Tue, 21 Jul 2026 10:52:04 +0000

Most engineers think Push is more advanced than Pull.

It's an easy conclusion to reach.

After all:

Polling feels old.
WebSockets feel modern.
Realtime feels better than waiting.

But some of the largest distributed systems in the world deliberately choose Pull.

Not because Pull is better.

Not because their engineers haven't heard of WebSockets.

Because every distributed system eventually faces a more important question:

Who is responsible for discovering change?

And the answer to that question determines where complexity lives.

At scale, Pull wastes requests.

Push wastes state.

Most architectures are simply deciding which waste is cheaper.

The Real Problem Isn't Communication

Imagine an order is created.

Order Created

Several services care about it:

Inventory Service
Analytics Service
Notification Service
Billing Service

The problem isn't generating information.

The problem is delivering it.

And there are only two fundamental ways to do that.

Pull

Consumers discover changes themselves.

Analytics ----> Order Service
Inventory ----> Order Service
Notification -> Order Service

Each consumer periodically asks:

"Anything new?"

The responsibility belongs to the consumer.

Push

The producer distributes changes.

Order Service
      |
      +----> Analytics
      |
      +----> Inventory
      |
      +----> Notification

The responsibility belongs to the producer.

That's it.

That's the entire Push vs Pull debate.

Polling, Long Polling, SSE, and WebSockets are merely different ways of implementing these two ideas.

Why Pull Refuses to Die

A common misconception among younger engineers is:

Push is the future.

Pull is a legacy workaround.

Reality is less exciting.

Many highly scalable systems intentionally choose Pull.

Kubernetes Is A Great Example

Imagine a Kubernetes cluster containing 10,000 nodes.

Many engineers expect the control plane to constantly push work to nodes.

Instead, nodes continuously ask:

Any new Pods for me?

The nodes pull work.

The control plane doesn't chase them.

Why?

Because Push concentrates responsibility.

Consider the alternative:

Control Plane
      |
      +--> Node 1
      +--> Node 2
      +--> Node 3
      ...
      +--> Node 10,000

Now the control plane must know:

Which nodes are alive
Which nodes are reachable
Which nodes need updates
Which connections failed

Complexity accumulates at the center.

With Pull:

Node 1 ---->
Node 2 ---->
Node 3 ---->
Node N ---->

Each node becomes responsible for its own synchronization.

This is a pattern you'll see repeatedly in distributed systems:

When coordination becomes expensive, systems often shift responsibility to the edges.

Pull tends to distribute complexity.

Polling: The Simplest Pull Strategy

Polling is often mocked because it seems inefficient.

A client repeatedly asks:

Anything new?

Every few seconds.

For example:

GET /orders/123/status

Most responses look identical:

{
  "status": "COOKING"
}

Again.

{
  "status": "COOKING"
}

Again.

{
  "status": "COOKING"
}

Eventually:

{
  "status": "DELIVERED"
}

This creates obvious waste.

Consider:

100,000 clients
poll every 5 seconds

That's:

20,000 requests/sec

even when nothing changes.

Which leads many engineers to conclude:

Polling doesn't scale.

But that's not entirely true.

Polling scales surprisingly well operationally.

Why?

Because stateless systems are easier to operate.

The server receives a request.

Returns a response.

Forgets everything.

No connection state.

No heartbeats.

No reconnection logic.

No presence tracking.

Sometimes infrastructure simplicity is worth more than network efficiency.

The Moment Systems Start Moving Toward Push

The problem with polling isn't that it doesn't work.

The problem is that most requests are useless.

A system designer eventually notices:

Request
No Change

Request
No Change

Request
No Change

Request
Actual Update

We're spending resources discovering nothing.

This realization leads to Long Polling.

Long Polling: Let Me Know When Something Happens

Instead of asking every few seconds:

Anything new?

The client asks:

Tell me when something changes.

The request remains open.

Client ---------------- Server
           waiting...

When an event appears:

New Message

The server responds immediately.

The client opens another request.

This dramatically reduces wasted requests.

The responsibility is still largely Pull-based.

But the behavior begins to resemble Push.

Long Polling became the bridge between traditional request-response systems and modern realtime systems.

SSE: Realtime Without Realtime Infrastructure

Long Polling still has a cost.

After every event:

Connection closes

A new connection must be established.

SSE removes that overhead.

One connection remains open.

Client ------------------------ Server

The server continuously streams updates.

AAPL = 210
AAPL = 211
AAPL = 212

No reconnects.

No repeated requests.

Just a stream.

This is why SSE quietly powers dashboards, monitoring systems, reporting platforms, and internal tooling.

Not because it's flashy.

Because it's operationally boring.

And boring systems are often excellent systems.

Why WebSockets Change Everything

WebSockets introduce a fundamentally different model.

Instead of:

Request
Response

You get:

Client <-----------------> Server

Both sides can communicate whenever they want.

This is essential for:

Chat systems
Multiplayer games
Collaborative editing
Trading platforms

The benefit is obvious:

Event Created
↓
Event Delivered

almost instantly.

Latency becomes tiny.

User experience improves dramatically.

Which is why founders love realtime.

The Cost Nobody Talks About

Most discussions about WebSockets focus on latency.

Experienced architects worry about something else:

State.

Polling wastes requests.

Push systems accumulate state.

A polling server can forget a client immediately after responding.

A WebSocket server cannot.

The server must remember:

User ID
Connection ID
Subscriptions
Heartbeat Status
Presence Information

And it must remember that information continuously.

Now imagine:

10 million connected users

Suddenly you're not managing APIs anymore.

You're managing connections.

And connections become infrastructure.

This is why large realtime companies eventually build:

Connection Gateways
Presence Services
Fanout Systems
Realtime Clusters
Event Brokers

The complexity didn't disappear.

It moved.

The Business Question Behind Push vs Pull

Engineers often evaluate Push and Pull through a technical lens.

Founders and CTOs usually care about a different question:

What will this cost us to operate?

Polling often creates more infrastructure waste.

Push often creates more engineering complexity.

Polling may consume more requests.

Realtime systems may require entire teams dedicated to connection management.

Founders often optimize for user experience.

CTOs often optimize for operational complexity.

Architects spend their careers balancing the two.

How Systems Usually Evolve

Most systems don't start with WebSockets.

They grow into them.

Stage 1
Polling

↓

Stage 2
Long Polling

↓

Stage 3
SSE

↓

Stage 4
WebSockets

↓

Stage 5
WebSockets + Pub/Sub + Fanout Services + Event Infrastructure

This evolution appears repeatedly across the industry.

Not because engineers love complexity.

Because scale eventually demands it.

The Hidden Tradeoff

Most engineers frame the decision like this:

Polling vs WebSockets

System designers frame it differently:

Waste vs State

Polling wastes requests.

Push systems accumulate state.

Pull systems tend to distribute responsibility.

Push systems tend to concentrate responsibility around delivery and state management.

Neither side wins.

Both pay.

The only question is:

Which cost is cheaper for your business?

The Mental Model That Actually Matters

Junior engineers often ask:

Should we use WebSockets?

Senior engineers ask:

Where should complexity live?

Should consumers be responsible for discovering change?

Or should producers be responsible for distributing it?

Because Push vs Pull is not really a networking discussion.

It's a complexity allocation discussion.

And every architecture eventually pays the bill.

The only question is who pays it.

Final Thought

Every Pull system eventually asks:

Why are we wasting so many requests?

Every Push system eventually asks:

Why are we managing so much state?

The goal of architecture is not to eliminate complexity.

The goal is to decide where it lives.

Synchronous vs Asynchronous Workloads: Why Modern Systems Cannot Afford To Wait

Anik Sikder — Sat, 18 Jul 2026 16:30:00 +0000

The Illusion of Simplicity

Most software begins with a simple interaction.

A user clicks a button.

User
  ↓
Request
  ↓
Application
  ↓
Response

The user asks for something.

The system performs the work.

The system returns an answer.

Simple.

Predictable.

Intuitive.

This pattern powers nearly every API on the internet.

When you log into your bank account:

POST /login

You expect an immediate response.

When you add an item to your cart:

POST /cart/items

You expect confirmation immediately.

In these situations, waiting makes sense because the user cannot proceed without the answer.

The interaction itself requires synchronization.

This is the essence of synchronous communication.

The client and server move forward together.

One waits for the other.

What Synchronous Really Means

Many developers define synchronous communication as:

Request → Wait → Response

Technically correct.

But incomplete.

From a systems perspective, synchronous communication means:

The lifetime of the work is coupled to the lifetime of the request.

This distinction is important.

Consider a checkout request.

Customer
    ↓
Checkout API
    ↓
Payment Service
    ↓
Database
    ↓
Response

The work begins when the request arrives.

The work ends before the response leaves.

Everything happens inside a single transaction boundary.

The request owns the work.

The work owns the response.

The three are tightly connected.

Waiting Is Not Free

One of the most important lessons in distributed systems is:

Waiting consumes resources.

While a request is waiting:

Memory remains allocated
Network connections remain open
Worker processes remain occupied
Thread pools remain partially blocked
Load balancers maintain state
Databases hold locks longer

At small scale this cost is invisible.

At large scale it becomes existential.

Imagine:

100 requests
×
100 milliseconds

No problem.

Now imagine:

100,000 requests
×
30 seconds

Suddenly the architecture itself becomes the bottleneck.

The system is no longer spending resources doing work.

It is spending resources waiting.

The Video Processing Thought Experiment

Imagine you're building YouTube.

A creator uploads a 4K video.

The upload completes.

Now the platform must:

Generate thumbnails

Transcode into multiple resolutions

Run copyright detection

Run moderation checks

Extract metadata

Replicate to storage regions

Update search indexes

The total processing time might be:

2 minutes

5 minutes

10 minutes

20 minutes

Now ask yourself:

Should the user wait?

A synchronous implementation would look like this:

User
   ↓
POST /upload
   ↓
20 Minutes Processing
   ↓
200 OK

This design immediately creates multiple problems.

Problem 1: Humans Hate Waiting

Most users start becoming uncomfortable after a few seconds.

After several minutes:

Loading...
Loading...
Loading...

Many assume the application is broken.

Even if the system is functioning perfectly.

Perception becomes reality.

Problem 2: Infrastructure Begins To Suffer

Imagine 50,000 creators uploading videos simultaneously.

If every request remains open for 20 minutes:

50,000 Open Connections

50,000 Active Request Contexts

50,000 Resource Reservations

The infrastructure collapses long before CPU becomes the bottleneck.

The system spends most of its capacity maintaining waiting clients.

Problem 3: Timeouts Become Inevitable

Every layer imposes limits.

Browser Timeout

Load Balancer Timeout

API Gateway Timeout

Reverse Proxy Timeout

Some component eventually gives up.

The work may still be running.

The client assumes it failed.

Now users retry.

Duplicate work appears.

System load increases further.

A reliability problem emerges from what initially looked like a latency problem.

The Fundamental Insight

The breakthrough realization was not technological.

It was conceptual.

Engineers eventually asked:

Does the user actually need the work completed?

Does the user simply need confirmation that the work has started?

These are completely different requirements.

For video uploads, the user doesn't need:

Video fully processed

The user needs:

We received your video.
Processing has started.

That insight changed the architecture of modern systems.

Decoupling Acceptance From Completion

Instead of:

Accept Request
      ↓
Perform Work
      ↓
Return Response

We do:

Accept Request
      ↓
Acknowledge Immediately
      ↓
Perform Work Later

Response:

202 Accepted

The request ends.

The work continues.

The user moves on.

The system moves on.

Everyone wins.

Enter Queues

The moment work stops happening immediately, a new question appears:

Where does the work wait?

The answer is usually a queue.

Think of a restaurant.

Customers place orders faster than chefs can cook.

The kitchen doesn't fail.

Orders simply wait.

Customer
     ↓
Order Queue
     ↓
Kitchen

Software systems work similarly.

API
   ↓
Queue
   ↓
Workers

The API accepts work.

Workers perform work.

The two sides become independent.

This decoupling is one of the most important scalability techniques ever invented.

Why Queues Are So Powerful

Queues solve several problems simultaneously.

Traffic Spikes

Without a queue:

10,000 uploads
        ↓
10,000 immediate processing jobs

Infrastructure explodes.

With a queue:

10,000 uploads
        ↓
Queue
        ↓
500 workers

The workload becomes manageable.

Failure Isolation

Suppose a video processor crashes.

Without a queue:

Request fails

With a queue:

Message remains

The work can be retried later.

Durability improves dramatically.

Elastic Scaling

When demand increases:

Queue Depth Increases

Add more workers.

When demand decreases:

Remove workers.

This elasticity is fundamental to cloud-native systems.

Background Jobs: Moving Work Off The Critical Path

A useful systems principle is:

Keep the request path as small as possible.

The critical path is everything that must happen before a response is returned.

For example:

Bad design:

User Registration
       ↓
Create User
Send Email
Generate Avatar
Sync CRM
Update Analytics
Create Recommendations
       ↓
Response

Good design:

User Registration
       ↓
Create User
       ↓
Response

Everything else becomes background work.

Send Email

Update Analytics

Generate Avatar

Create Recommendations

The response becomes dramatically faster.

Reliability improves.

User experience improves.

System throughput improves.

Event-Driven Systems: The Next Evolution

As organizations grow, multiple services become interested in the same event.

Consider an e-commerce platform.

An order is placed.

Who cares?

Inventory Service

Payment Service

Shipping Service

Analytics Service

Email Service

Fraud Detection Service

Potentially dozens of consumers.

A synchronous design might create this:

Order Service
      ↓
Inventory
      ↓
Email
      ↓
Analytics
      ↓
Shipping

Every dependency increases latency.

Every dependency increases failure risk.

Every dependency increases coupling.

Instead, modern systems often publish an event.

Order Created
       ↓
Event Broker
       ↓
Many Consumers

The producer no longer needs to know who is listening.

This is the foundation of event-driven architecture.

Does Asynchronous Mean Better?

No.

This is where many engineers make a mistake.

Asynchronous systems introduce new challenges:

Eventual Consistency

Duplicate Messages

Out-of-Order Events

Retry Logic

Observability Complexity

Distributed Debugging

You exchange waiting problems for coordination problems.

The trade-off is often worthwhile.

But it is never free.

The Real Lesson

The distinction between synchronous and asynchronous workloads is not about APIs, queues, or message brokers.

It is about understanding the cost of waiting.

System design becomes much clearer when you start asking a different question.

Not:

Can this work be asynchronous?

But:

Does anyone truly need to wait for this work to finish?

The most scalable systems in the world are often built around a simple idea:

Acknowledge immediately.

Process independently.

Coordinate eventually.

That single shift in thinking is responsible for much of modern distributed architecture, from YouTube's video pipeline, to Stripe's payment processing, to Amazon's order fulfillment systems.

And once you begin seeing systems through that lens, you'll notice that many of the world's largest platforms are really just sophisticated mechanisms for avoiding unnecessary waiting.

Request-Response: The Foundation of Modern APIs

Anik Sikder — Mon, 13 Jul 2026 18:05:49 +0000

Most developers use Request-Response every day.

Few stop to think about what actually happens after clicking a button.

You open an app.

You tap "Login".

A response appears almost instantly.

Simple, right?

Not exactly.

Behind that seemingly simple interaction lies one of the most important communication patterns in software engineering:

Request-Response.

Whether you're using ChatGPT, ordering food through Uber Eats, checking your bank balance, or watching Netflix, countless Request-Response interactions occur every second.

Understanding this pattern is one of the first steps toward understanding modern backend engineering.

What Is Request-Response?

At its core, Request-Response is a conversation between two systems.

One system asks for something.

Another system answers.

Client                    Server
   |                         |
   |------ Request --------->|
   |                         |
   |<----- Response ---------|
   |                         |

The client initiates communication.

The server processes the request and returns a response.

This interaction is typically short-lived and synchronous.

The client sends a request and waits for an answer.

A Real-World Analogy

Imagine you're sitting in a restaurant.

You call the waiter.

Customer -> "I'd like a burger."

The waiter takes your order to the kitchen.

The kitchen prepares the meal.

The waiter returns with your food.

Kitchen -> "Here's your burger."

That's Request-Response.

Customer = Client
Waiter = Network
Kitchen = Server
Burger = Response

Most web applications operate using exactly this pattern.

The Journey of a Request

Consider a simple login request.

POST /login

It may look simple from the browser's perspective.

But internally:

Browser
   |
Load Balancer
   |
API Gateway
   |
Authentication Service
   |
Database

The response must travel back through the same chain.

Database
   |
Authentication Service
   |
API Gateway
   |
Load Balancer
   |
Browser

Every step introduces latency, failure possibilities, and complexity.

Latency: The Hidden Cost of Distance

Latency is the time required for a request to travel through the system and return a response.

Request Sent --------------------->

<-------------------- Response Received

Users don't care about architecture diagrams.

They care about speed.

When someone clicks a button, they expect a response immediately.

Even small delays are noticeable.

Typical user perception:

Response Time	User Experience
0–100 ms	Instant
100–300 ms	Fast
300–1000 ms	Noticeable
1–3 sec	Slow
3+ sec	Frustrating

At scale, reducing latency becomes a competitive advantage.

This is one reason companies invest heavily in:

CDNs
Caching
Edge Computing
Database Optimization
Load Balancing

Timeouts: Waiting Forever Is Not an Option

Imagine calling a restaurant and nobody answers.

How long should you wait?

Five seconds?

Five minutes?

An hour?

Software faces the same problem.

A timeout defines the maximum amount of time a system is willing to wait for a response.

Client ---- Request ---->
                ...
                ...
                ...
Timeout Reached

Without timeouts, systems can become stuck waiting forever.

This leads to:

Hanging requests
Resource exhaustion
Poor user experience

Every production-grade system uses timeouts.

Retries: What If the Request Fails?

Networks are imperfect.

Packets get lost.

Servers restart.

Databases become temporarily unavailable.

A single failure doesn't necessarily mean the operation should fail.

Instead, many systems retry.

Attempt #1 -> Failed

Attempt #2 -> Failed

Attempt #3 -> Success

Retries improve reliability.

But they also introduce a dangerous problem.

What if the original request actually succeeded?

Idempotency: Preventing Duplicate Operations

Imagine clicking:

Pay Now

The payment succeeds.

But the response never reaches your browser.

Your application thinks the request failed.

It retries.

Charge Card

Again.

Without protection, the customer could be charged twice.

This is why payment systems use idempotency.

An idempotent operation produces the same result even if executed multiple times.

Request ID: abc123

If the same request arrives again:

Request ID: abc123

The server recognizes it and returns the previous result instead of processing the payment again.

This concept is critical in systems like:

Stripe
PayPal
Banking Platforms
Order Processing Systems

Fan-Out: One Request Can Become Many

A request rarely stays simple for long.

Imagine opening a product page.

The backend may need:

Product Service
Review Service
Inventory Service
Pricing Service
Recommendation Service

One incoming request becomes many downstream requests.

                 Product
                /
Client ---- API Gateway
                \
                 Reviews

                 Inventory

                 Pricing

This pattern is called Fan-Out.

Fan-Out increases functionality.

But it also increases risk.

If one dependency becomes slow, the entire response can become slow.

Cascading Failures

Now imagine the Review Service becomes overloaded.

Requests begin timing out.

The Product Service waits.

Threads become blocked.

Connection pools fill up.

More requests pile up.

Soon:

Review Service Failure
        |
        v
Product Service Slow
        |
        v
API Gateway Slow
        |
        v
Entire Application Slow

A small issue spreads throughout the system.

This is called a Cascading Failure.

Many major outages start exactly this way.

A single dependency struggles.

Everything connected to it suffers.

Observability: Seeing What the System Sees

When users complain:

"The app feels slow."

Where exactly is the problem?

The database?

The cache?

The network?

The payment service?

Without visibility, debugging becomes guesswork.

Modern systems rely on observability.

Three pillars are commonly used:

Logs

Individual events.

User logged in
Payment created
Order shipped

Metrics

System health measurements.

CPU Usage
Memory Usage
Request Rate
Error Rate
Latency

Traces

The complete journey of a request.

Client
  -> Gateway
     -> Auth Service
        -> Database

Tracing reveals where time is spent.

At scale, observability becomes essential.

Why Request-Response Eventually Becomes a Bottleneck

Request-Response is simple.

That's its greatest strength.

But it's also its limitation.

The client must wait.

Request --->

<--- Response

No response means no progress.

As systems grow, engineers begin exploring alternatives:

Polling
Long Polling
Server-Sent Events (SSE)
WebSockets
Pub/Sub
Event-Driven Architectures

These patterns exist because traditional Request-Response is not always enough.

But every one of them builds upon the foundation established by Request-Response.

Final Thoughts

Request-Response appears deceptively simple.

A client asks.

A server answers.

Yet hidden beneath that simplicity are some of the most important challenges in software engineering:

Latency
Timeouts
Retries
Idempotency
Fan-Out
Cascading Failures
Observability

Understanding these concepts is what separates someone who can build APIs from someone who can design reliable systems.

Before learning WebSockets, Event Streaming, or Distributed Systems, it's worth mastering the communication pattern that powers nearly every application on the internet:

Request-Response.

HTTP/3: Why the Web Finally Moved Beyond TCP

Anik Sikder — Fri, 10 Jul 2026 17:29:42 +0000

In the previous article, we explored how HTTP/2 transformed web communication.

Instead of opening multiple TCP connections, HTTP/2 introduced multiplexing, allowing many streams to share a single connection.

This was a major breakthrough.

Websites loaded faster.

Connections became more efficient.

Servers handled resources more intelligently.

For a while, it seemed like the web's communication problems had finally been solved.

But engineers soon discovered an uncomfortable truth:

HTTP/2 solved many of HTTP's problems.

It did not solve all of TCP's problems.

And because HTTP/2 still relied on TCP, some bottlenecks remained.

To understand those bottlenecks, imagine you're watching a Netflix movie on your phone.

You're connected to your home Wi-Fi.

Everything is smooth.

Then you leave your house.

Your phone switches from:

Wi-Fi
↓
5G

For a brief moment, the video freezes.

A loading spinner appears.

A few seconds later, playback continues.

Most users blame the network.

But engineers ask a different question:

Why did the connection have to struggle in the first place?

Questions like this eventually led to one of the biggest protocol changes in the history of the web:

HTTP/3.

The Hidden Success of HTTP/2

When HTTP/2 arrived, it solved a huge problem.

Instead of opening many TCP connections:

Browser
 ├── TCP 1
 ├── TCP 2
 ├── TCP 3
 ├── TCP 4
 ├── TCP 5
 └── TCP 6

HTTP/2 introduced multiplexing.

Now everything could travel through one connection.

One TCP Connection
│
├── HTML
├── CSS
├── JavaScript
├── Images
└── Fonts

Less overhead.

Better efficiency.

Faster websites.

For a while, it looked like the problem was solved.

Then reality struck.

The Problem Nobody Could See

Imagine a highway with five lanes.

Cars are moving perfectly.

Suddenly a truck crashes in Lane 2.

What should happen?

Common sense says:

Lane 2 slows down.

Lanes 1, 3, 4, and 5 continue moving.

But TCP behaves differently.

TCP says:

Nobody moves until the missing vehicle is accounted for.

Everything waits.

Even traffic that wasn't affected.

This is essentially what happens when packet loss occurs.

Understanding Packet Loss

Data sent across the internet is divided into packets.

Imagine sending:

Packet 1
Packet 2
Packet 3
Packet 4
Packet 5

Now suppose Packet 3 disappears.

Maybe a router drops it.

Maybe Wi-Fi interference occurs.

Maybe a mobile network briefly weakens.

The receiver gets:

Packet 1 ✅
Packet 2 ✅
Packet 3 ❌
Packet 4 ✅
Packet 5 ✅

Humans would probably say:

Great.

We already have 1, 2, 4, and 5.

Let's continue.

TCP disagrees.

TCP's Obsession With Order

TCP was designed decades ago.

Its primary mission was reliability.

If data is sent:

TCP guarantees:

No missing pieces.

No reordering.

No shortcuts.

This reliability is amazing for:

Banking
Email
File Downloads
Database Replication

But for modern web applications, it creates a hidden cost.

The Waiting Game

Imagine five HTTP/2 streams:

Connection
│
├── Stream A → HTML
├── Stream B → CSS
├── Stream C → JavaScript
├── Stream D → Images
└── Stream E → Fonts

Now one packet carrying image data gets lost.

Logically, only the image should be affected.

But because all streams share one TCP connection:

HTML        ⏳ Waiting
CSS         ⏳ Waiting
JavaScript  ⏳ Waiting
Images      ⏳ Waiting
Fonts       ⏳ Waiting

Everything slows down.

Even resources that arrived successfully.

This is called:

TCP Head-of-Line Blocking.

And it became one of the biggest remaining performance problems on the modern web.

Why Mobile Networks Made Things Worse

Back in the early 2000s:

Desktop computers dominated
Wired connections were common

Today:

Smartphones dominate traffic
Users move constantly
Networks change frequently

A user may switch:

Home Wi-Fi
      ↓
Coffee Shop Wi-Fi
      ↓
4G
      ↓
5G

Packet loss is normal.

Temporary interruptions are normal.

Modern protocols must assume imperfect networks.

TCP was designed for a different era.

Engineers Asked a Radical Question

For decades the stack looked like this:

HTTP
 ↓
TCP
 ↓
IP

Nobody questioned it.

Using TCP felt as natural as using electricity.

Then engineers asked:

What if HTTP doesn't need TCP?

That question changed everything.

Meet QUIC

Google engineers began experimenting with a new transport protocol called QUIC.

Instead of building on TCP:

HTTP/2
   ↓
 TCP

They built on UDP:

HTTP/3
   ↓
 QUIC
   ↓
 UDP

At first, this sounds crazy.

UDP is famous for being unreliable.

The Pizza Delivery Analogy

Think of TCP as a delivery company.

Every pizza must arrive.

Every pizza must arrive in order.

If Pizza #3 is delayed:

Pizza 4 waits
Pizza 5 waits
Pizza 6 waits

Maximum reliability.

But sometimes unnecessary waiting.

UDP works differently.

Send Pizza
     ↓
Hope It Arrives

Much faster.

Much simpler.

But not reliable enough for the web.

QUIC combines the best of both worlds.

The Genius of QUIC

QUIC provides:

UDP Speed
      +
TCP Reliability

But it adds one critical improvement.

Streams become independent.

Imagine:

Stream A
Stream B
Stream C

If Stream A loses a packet:

Stream A waits

But:

Stream B continues
Stream C continues

This is the breakthrough.

One problem no longer freezes everything.

Why This Matters

Think about modern applications:

YouTube
Netflix
ChatGPT
Discord
Google Docs
Figma

These applications constantly exchange data.

Small delays affect user experience.

Reducing unnecessary waiting directly improves responsiveness.

HTTP/3 was designed for exactly this world.

Another Hidden Superpower: Faster Connections

Traditional HTTPS connections require several steps:

TCP Handshake
      ↓
TLS Handshake
      ↓
Data Transfer

Every step adds latency.

QUIC combines and optimizes much of this process.

In some situations, returning users can send data immediately.

This is called:

0-RTT (Zero Round Trip Time)

Less waiting.

Faster interactions.

Happier users.

Connection Migration: The Mobile Superpower

Remember the Netflix example?

With TCP, changing networks often means starting over.

With QUIC:

Wi-Fi
   ↓
5G

The connection can survive.

The session continues.

The user experiences fewer interruptions.

This is one reason HTTP/3 performs so well on mobile devices.

The Big Picture

Every major HTTP version solved the biggest bottleneck of its era.

HTTP/1.1
↓
Too Many Requests

HTTP/2
↓
Connection Inefficiency

HTTP/3
↓
Transport-Level Blocking

The story of HTTP is really the story of engineers continuously removing obstacles between users and information.

Key Takeaways

HTTP/2 solved many HTTP/1.1 inefficiencies through multiplexing.
TCP-level Head-of-Line Blocking still remained.
Packet loss on one stream could affect unrelated streams.
Modern mobile networks made this limitation more noticeable.
QUIC was built on UDP to provide a more flexible transport layer.
HTTP/3 uses QUIC instead of TCP.
Independent streams reduce unnecessary waiting.
Features like 0-RTT and Connection Migration improve real-world performance.

One-Sentence Summary

HTTP/2 made one connection smarter; HTTP/3 made sure one lost packet could no longer slow down the entire conversation.

HTTP/2: The Protocol That Stopped the Connection Explosion

Anik Sikder — Sun, 05 Jul 2026 16:30:00 +0000

In the previous article, we explored why HTTP/1.1 eventually became a bottleneck.

The web had evolved from a collection of simple documents into a platform for complex applications.

Browsers were no longer requesting a handful of files.

They were requesting hundreds.

To cope with these growing demands, browser vendors adopted a workaround:

Browser
 ├── TCP Connection 1
 ├── TCP Connection 2
 ├── TCP Connection 3
 ├── TCP Connection 4
 ├── TCP Connection 5
 └── TCP Connection 6

The strategy worked.

Pages loaded faster.

Users were happier.

But underneath the surface, a new problem was emerging.

The web was becoming dependent on opening more and more connections just to maintain acceptable performance.

Engineers realized something important:

The problem wasn't the network. The problem was how HTTP used the network.

HTTP/2 was created to rethink that relationship.

The Fundamental Shift

HTTP/1.1 was built around a relatively simple assumption:

Request
↓
Response

Repeat this process enough times and eventually the page loads.

HTTP/2 challenged that model.

Instead of asking:

How can we create more connections?

It asked:

How can we make a single connection dramatically more efficient?

That single idea shaped the entire protocol.

Why More Connections Were Never the Real Solution

Imagine managing a warehouse.

You receive 1,000 orders per hour.

One approach is to hire more managers.

Another approach is to improve the workflow.

HTTP/1.1 effectively chose the first option.

More traffic?

Open more TCP connections.

Need more resources?

Open even more connections.

The result was increasing overhead:

More TCP handshakes
More memory allocation
More connection state tracking
More CPU usage
More congestion on busy networks

Performance improved, but efficiency suffered.

HTTP/2 aimed to solve the workflow problem instead.

The Birth of Multiplexing

The most important innovation in HTTP/2 is multiplexing.

To understand why, imagine ordering five items from a warehouse:

1. HTML
2. CSS
3. JavaScript
4. Product Images
5. Fonts

In HTTP/1.1, resources often competed with one another.

In HTTP/2, requests become independent streams.

TCP Connection
│
├── Stream 1 → HTML
├── Stream 2 → CSS
├── Stream 3 → JavaScript
├── Stream 4 → Images
└── Stream 5 → Fonts

All streams share the same connection.

Instead of waiting for one resource to finish before another can progress, data from multiple streams can be interleaved.

This means the server can send:

HTML Chunk
CSS Chunk
Image Chunk
JavaScript Chunk
HTML Chunk
Font Chunk
Image Chunk

The browser reassembles everything correctly.

This seemingly simple change transformed web performance.

What Actually Happens Under the Hood?

Multiplexing is often explained as:

Multiple requests at the same time.

While technically true, it misses the interesting part.

HTTP/2 introduces a concept called frames.

Every request and response is broken into smaller units called frames.

Request
    ↓
 Frames
    ↓
 Stream
    ↓
 Connection

Think of a large book being split into hundreds of pages.

Instead of delivering one complete book at a time, pages from many books can travel together.

Example:

Frame A1
Frame B1
Frame C1
Frame A2
Frame B2
Frame C2

The browser knows which frame belongs to which stream.

This allows continuous utilization of the connection.

Idle time drops dramatically.

Bandwidth utilization improves.

Binary Framing: The Invisible Revolution

One of the biggest architectural changes in HTTP/2 is something users never see.

HTTP/1.1 is text-based.

A request looks like this:

GET /products HTTP/1.1
Host: example.com

Humans can read it.

Computers can read it too.

But computers don't naturally think in text.

They think in binary.

HTTP/2 introduces a binary framing layer.

Instead of transmitting textual messages directly:

HTTP Message
        ↓
Binary Frames
        ↓
TCP

This allows:

Faster parsing
More predictable processing
Reduced protocol complexity
Better performance under heavy traffic

The protocol becomes easier for machines to handle efficiently.

Header Compression: Solving a Hidden Cost

As websites grew, headers became surprisingly large.

Consider a modern request:

Cookie: ...
Authorization: ...
User-Agent: ...
Accept-Language: ...
Cache-Control: ...

Many of these values repeat across requests.

In HTTP/1.1, they are often transmitted repeatedly.

This creates waste.

HTTP/2 introduces HPACK.

HPACK maintains a dynamic table of previously transmitted header values.

Instead of sending:

Authorization: Bearer abc123...

Again and again, the client can reference a previously stored value.

Conceptually:

Header Table

#1 Authorization
#2 Cookie
#3 User-Agent

Future requests simply reference the index.

Less data travels over the network.

Latency decreases.

Bandwidth usage improves.

Prioritization: Not All Resources Are Equal

Imagine loading an e-commerce homepage.

Which resource matters first?

Hero Image
Product Grid
Analytics Script
Tracking Pixel
Chat Widget

Clearly not everything has equal importance.

HTTP/2 allows streams to carry priority information.

The browser can effectively say:

Render the visible page first.

Fetch less important resources later.

This improves perceived performance.

Users see content sooner.

Did HTTP/2 Eliminate Head-of-Line Blocking?

This is where things become interesting.

Many developers assume HTTP/2 completely solved Head-of-Line Blocking.

It didn't.

It solved one version of it.

HTTP-level blocking was dramatically reduced through multiplexing.

However, HTTP/2 still runs on TCP.

TCP guarantees ordered delivery.

Consider:

Packet 1
Packet 2
Packet 3
Packet 4
Packet 5

If Packet 3 is lost:

Packet 4 waits
Packet 5 waits

Even if those packets belong to different streams.

The operating system cannot deliver later packets until the missing packet arrives.

This creates TCP-level Head-of-Line Blocking.

HTTP/2 improved the application layer.

But the transport layer still had limitations.

Real-World Impact

HTTP/2 fundamentally changed how modern websites are delivered.

Benefits included:

Fewer TCP connections
Lower network overhead
Better bandwidth utilization
Faster page rendering
Improved mobile performance
Reduced server resource consumption

For large-scale applications serving millions of users, these improvements were substantial.

HTTP/2 became one of the most important protocol upgrades in the history of the web.

The Remaining Problem

HTTP/2 solved many issues that plagued HTTP/1.1.

But one major bottleneck survived.

TCP itself.

As mobile usage exploded and network conditions became less predictable, packet loss became increasingly expensive.

Engineers began asking a new question:

What if the transport layer itself needed to change?

That question eventually led to QUIC.

And QUIC became the foundation of HTTP/3.

Key Takeaways

HTTP/2 was designed to eliminate the inefficiencies of HTTP/1.1.
Multiplexing allowed multiple streams to share a single connection.
Binary framing made communication more machine-efficient.
HPACK reduced repetitive header transmission.
Stream prioritization improved perceived page performance.
HTTP-level Head-of-Line Blocking was largely solved.
TCP-level Head-of-Line Blocking remained.
That remaining limitation ultimately inspired HTTP/3.

One-Sentence Summary

HTTP/1.1 scaled by opening more connections; HTTP/2 scaled by making a single connection smarter.

Why HTTP/1.1 Eventually Became a Bottleneck

Anik Sikder — Wed, 01 Jul 2026 17:13:07 +0000

To understand HTTP/2 and HTTP/3, we first need to understand the problem they were designed to solve.

Many developers think protocol upgrades happen because engineers want newer technology.

In reality, protocols evolve because existing systems hit limits.

HTTP/2 and HTTP/3 were not created because HTTP/1.1 was broken.

They were created because the modern web outgrew it.

The Web HTTP/1.1 Was Designed For

Imagine it's 2005.

You open a typical website.

The browser requests:

index.html
style.css
logo.png

That's it.

A handful of files.

The total page size might be a few hundred kilobytes.

For this type of website, HTTP/1.1 performs reasonably well.

Now fast-forward to today.

Open a modern e-commerce platform, social network, or SaaS application.

Your browser may request:

HTML
CSS
JavaScript Bundles
Fonts
Icons
Product Images
Videos
Analytics Scripts
Tracking Pixels
API Requests
Recommendation Engines
Chat Widgets
Third-Party Integrations

Instead of three requests, there may be hundreds.

A modern webpage is often closer to an application than a document.

The internet changed dramatically.

HTTP/1.1 largely remained the same.

Understanding the Real Problem

At first glance, downloading 100 files doesn't sound difficult.

The challenge isn't the files themselves.

The challenge is coordination.

Imagine a warehouse receiving hundreds of orders.

If workers can only process one order at a time, a queue quickly forms.

The same idea applies to network communication.

The browser wants many resources.

The server has many resources.

The protocol determines how efficiently they can communicate.

The Single-Lane Highway Problem

Think of a highway with only one lane.

🚗 HTML
   ↓
🚗 CSS
   ↓
🚚 Large Image
   ↓
🚗 JavaScript
   ↓
🚗 Font File

Everything must travel through the same lane.

If a large truck blocks traffic, smaller vehicles behind it cannot pass.

This is exactly what happens when network requests become serialized.

One slow response can delay many others.

The result is unnecessary waiting.

The Restaurant Analogy

Imagine a restaurant with only one waiter.

A customer places an order.

The waiter walks to the kitchen.

The waiter waits.

The food is prepared.

The waiter returns.

Only then can the next customer be served.

Customer 1
    ↓
 Waiter
    ↓
 Kitchen

Customer 2 waits...

Customer 3 waits...

Customer 4 waits...

As the restaurant grows busier, waiting time increases.

The problem is not the customers.

The problem is the process.

HTTP/1.1 faced a similar challenge as web applications became more complex.

What Is Head-of-Line Blocking?

Suppose the browser requests:

1. HTML
2. CSS
3. app.js
4. hero-image.jpg
5. font.woff

Now imagine the image is several megabytes.

HTML             ✅ Complete
CSS              ✅ Complete
hero-image.jpg   ⏳ Slow
app.js           ❌ Waiting
font.woff        ❌ Waiting

The image becomes the bottleneck.

Resources behind it must wait.

This phenomenon is called Head-of-Line Blocking.

A single slow transfer can reduce the performance of everything behind it.

Think of it like a traffic accident blocking an entire lane of vehicles.

The vehicles themselves are not the problem.

The blockage is.

Browser Engineers Fought Back

Browser vendors quickly realized that relying on a single connection was inefficient.

Instead of waiting for one connection to finish, browsers started opening multiple TCP connections.

A simplified example:

Browser
 ├── TCP Connection 1
 ├── TCP Connection 2
 ├── TCP Connection 3
 ├── TCP Connection 4
 ├── TCP Connection 5
 └── TCP Connection 6

Now multiple files could be downloaded simultaneously.

This significantly improved perceived performance.

For many years, browsers commonly opened around six parallel connections per domain.

At first, this seemed like the perfect solution.

But it introduced new costs.

Why More Connections Create More Overhead

Every TCP connection is not free.

Before any useful data can be transferred, a connection must be established.

Client
   ↓
 SYN
   ↓
 SYN-ACK
   ↓
 ACK
   ↓
 Connection Ready

Only after the TCP handshake can data begin flowing.

If six connections are opened:

6 Handshakes
6 Connection States
6 Buffers
6 Resource Allocations

The browser spends more effort.

The server spends more effort.

The network carries more overhead.

What started as a workaround eventually became part of the problem.

Engineers realized they were compensating for protocol limitations rather than eliminating them.

The Turning Point

By the early 2010s, the web had become dramatically different from the web HTTP/1.1 was originally designed for.

Developers were building:

Gmail-like applications
Facebook-style feeds
Streaming platforms
Real-time dashboards
Large e-commerce systems

The industry needed a way to efficiently transfer many resources without opening dozens of connections.

The goal became clear:

Instead of using many TCP connections inefficiently, use one connection intelligently.

That idea became the foundation of HTTP/2.

Key Takeaways

HTTP/1.1 was designed for a much simpler web.
Modern applications require far more network requests than early websites.
Head-of-Line Blocking can cause slow resources to delay others.
Browsers worked around this limitation by opening multiple TCP connections.
Multiple connections improved performance but increased overhead.
The web eventually reached a point where workarounds were no longer enough.
HTTP/2 was created to solve these architectural limitations more efficiently.

👨‍🍳 Part 4: Coroutines Waiters Who Listen

Anik Sikder — Thu, 30 Oct 2025 15:00:00 +0000

In the last episode, our restaurant became a smooth-running machine with sous-chefs, conveyor belts, and kitchen gadgets all powered by lazy pipelines.

But what if our waiters could not only serve dishes but also take your order while serving?

Welcome to the world of coroutines where generators become two-way communication channels.

🧠 1. From Generators → Coroutines

So far, our waiters (generators) could only send food out using yield.
Now we’ll make them listen too by using .send().

🍽️ Normal generator (one-way)

def waiter():
    yield "Serving dish 1"
    yield "Serving dish 2"

w = waiter()
print(next(w))
print(next(w))

Output:

Serving dish 1
Serving dish 2

The waiter talks, we listen.
But what if we want to talk back?

🎤 2. Enter `.send()` → Talking to Waiters

With .send(), you can send data into a running generator.
Let’s make the waiter respond to your requests:

def interactive_waiter():
    print("👨‍🍳 Ready to take your order.")
    while True:
        dish = yield "What would you like?"
        print(f"🍲 Serving {dish}...")

w = interactive_waiter()
print(next(w))          # start the waiter
print(w.send("pasta"))  # send order
print(w.send("steak"))

Output:

👨‍🍳 Ready to take your order.
What would you like?
🍲 Serving pasta...
What would you like?
🍲 Serving steak...
What would you like?

✨ next() starts the generator up to the first yield.
✨ send() sends a value into the paused generator.

Think of .send() as the customer talking back to the waiter mid-meal.

🧾 3. Real-World Mini Project: Live Event Processor

Imagine we’re building a live analytics system that reacts to new events as they stream in.

def event_collector():
    total = 0
    try:
        while True:
            value = yield f"Total so far: {total}"
            total += value
    except GeneratorExit:
        print(f"Final total: {total}")

Now we can feed it events dynamically:

collector = event_collector()
print(next(collector))        # start
print(collector.send(10))
print(collector.send(5))
print(collector.send(20))
collector.close()             # stop waiter

Output:

Total so far: 0
Total so far: 10
Total so far: 15
Total so far: 35
Final total: 35

👉 .close() politely tells the waiter “You can go home now.”
👉 .throw() (optional) lets you raise an exception inside the generator.

🧨 4. `.throw()` → Throw Problems at the Waiter

Sometimes, the kitchen runs into trouble 🍳💥.
You can throw exceptions into a coroutine to simulate errors.

def chef():
    try:
        while True:
            dish = yield
            print(f"Cooking {dish}")
    except ValueError:
        print("🔥 Wrong ingredient!")

c = chef()
next(c)
c.send("pasta")
c.throw(ValueError)   # injects error
c.send("salad")

Output:

Cooking pasta
🔥 Wrong ingredient!
Cooking salad

👉 throw() sends an exception inside the generator, where you can handle it gracefully.

🧩 5. Coroutine Pipelines → Reactive Conveyor Belts

Now let’s combine our powers from earlier delegation + coroutines.

We’ll build a live restaurant pipeline:

Orders stream in.
One coroutine filters vegetarian dishes.
Another coroutine logs them.

def logger():
    while True:
        item = yield
        print(f"🧾 Logged: {item}")

def vegetarian_filter(target):
    while True:
        dish = yield
        if "🥩" not in dish:
            target.send(dish)

log = logger()
next(log)
veg = vegetarian_filter(log)
next(veg)

# Send live dishes
for dish in ["🥗 salad", "🍝 pasta", "🥩 steak", "🍰 cake"]:
    veg.send(dish)

Output:

🧾 Logged: 🥗 salad
🧾 Logged: 🍝 pasta
🧾 Logged: 🍰 cake

This is a real coroutine pipeline: data flows in, stage by stage, with each coroutine doing one job and passing it onward.

⚙️ 6. Async/Await → Waiters in Parallel (Modern Coroutines)

Python 3.5+ gave us asyncio, where coroutines can multitask
many waiters serving at once, without blocking each other!

import asyncio

async def waiter(name, delay):
    print(f"{name} started taking orders...")
    await asyncio.sleep(delay)
    print(f"{name} finished!")

async def main():
    await asyncio.gather(
        waiter("👨‍🍳 Chef 1", 2),
        waiter("👩‍🍳 Chef 2", 3)
    )

asyncio.run(main())

Output:

👨‍🍳 Chef 1 started taking orders...
👩‍🍳 Chef 2 started taking orders...
👨‍🍳 Chef 1 finished!
👩‍🍳 Chef 2 finished!

Multiple waiters (async coroutines) handle customers simultaneously no blocking, no chaos.

🎨 ASCII Mental Model

 Customer
    ↓
 [ interactive coroutine ]
    ↓
 [ filter coroutine ]
    ↓
 [ logger coroutine ]

Each waiter not only serves dishes but talks, reacts, and coordinates in real time.

🎬 Wrap-Up: The Grand Kitchen Finale

Over the 4 parts, we’ve built a complete mental model of Python iteration from solo waiters to a full restaurant orchestra:

Part	Concept	Analogy	Key Idea
1	Iterables & Generators	Buffet & Waiter	Lazy one-way serving
2	`itertools`	Kitchen Gadgets	Tools for smart iteration
3	Delegation	Sous-Chefs & Pipelines	Composable generator chains
4	Coroutines	Interactive Waiters	Two-way, reactive pipelines

🎉 Final Takeaway:

Iterators feed data, generators process data, and coroutines interact with data.

Python’s iteration model isn’t just about looping
it’s a design pattern for scalable, memory-friendly, and interactive data flow.