Real-Time Web Communication: Long/Short Polling, WebSockets, and SSE Explained + Next.js code

Backstory: The Unexpected Interview Question

A few months ago, I was in the middle of a technical interview for a mid-level front-end position. Things were going smoothly until I was hit with a question that caught me slightly off guard.

"Imagine you need a form of constant communication to check something every second until you retrieve something you need.

For example, you want to keep checking if a payment has been successful, like in an e-commerce setup. How would you approach this?"

I responded cautiously, “I think you could implement WebSockets to handle that.”

The interviewer smiled. "That’s a good solution, but there are other, arguably better, options depending on the situation."

And that’s when we dove into a conversation about various approaches to real-time communication, including Long Polling, Short Polling, WebSockets, and finally, Server-Sent Events (SSE), which is arguably the best choice for a unidirectional data stream, like in our payment example.

We also discussed choosing the right database for handling these constant, yet lightweight requests without draining server resources. In that context, Redis came up, known for its simplicity and efficiency in managing these types of requests.

This conversation stuck with me. I realized that while WebSockets get a lot of attention, there’s a wide array of techniques that, when understood, can optimize the way we manage real-time communication. Today, I want to break down these four approaches, when to use each, and their pros and cons in a clear, engaging way. By the end, you’ll have a solid understanding of why Server-Sent Events (SSE) often shine for one-way, real-time communication.

Before I begin, huge thanks to Marcos, the experienced Senior Software Engineer who conducted that chat and inspired me to write this article months later, which I much appreciated even though I didn't get the job! :)

The Four Methods of Real-Time Communication

Before jumping into the SSE example, let’s break down the four methods we discussed during that interview:

1. Short Polling

Short polling is probably the simplest method. It involves making a request to the server at regular intervals, asking, “Do you have new data?” The server responds with the current state—whether or not there’s anything new.

Upside:

• Easy to implement
• Works with traditional HTTP requests

Downside:

• It’s resource-heavy. You’re making frequent requests, even when no new data is available.
• Can increase server load and network traffic, which becomes inefficient for frequent checks like payment status updates.

Best for: Small, low-frequency data updates, such as a stock market price to update every minute or so.

2. Long Polling

Long polling takes short polling a step further. The client repeatedly requests information from the server, but instead of the server responding right away, it holds onto the connection until new data is available. Once data is sent back, the client immediately opens a new connection and repeats the process.

Upside:

• More efficient than short polling because the server only responds when necessary - it's really fast.
• Compatible with browsers and HTTP/HTTPS protocols.

Downside:

• Still requires reopening connections repeatedly, leading to inefficiency over time - expensive resources.
• Slightly more complex than short polling.

Best for: Situations where real-time communication is needed but WebSockets/SSE might be overkill (e.g., chat applications).

3. WebSockets

WebSockets are a more modern solution that provides full-duplex communication between client and server. Once a connection is opened, both sides can send data freely without re-establishing connections - which defines a bidirectional communication.

Upside:

• True real-time communication with minimal latency.
• Great for bi-directional communication (e.g., real-time games, chat apps).

Downside:

• More complex to implement than polling or SSE.
• WebSockets aren’t always ideal for one-way communication or less frequent updates, as they can consume resources by maintaining open connections.
• May need firewall configuration.

Best for: Applications requiring constant two-way communication, like multiplayer games, collaborative tools, chat applications, or real-time notifications.

4. Server-Sent Events (SSE)

Finally, we come to Server-Sent Events (SSE), the hero of our payment example. SSE creates a one-way connection where the server sends updates to the client. Unlike WebSockets, this is unidirectional—the client doesn’t send data back.

Upside:

• Ideal for one-way data streams like news feeds, stock tickers, or payment status updates.
• Lightweight and simpler to implement than WebSockets.
• Uses the existing HTTP connection, so it’s well-supported and firewall-friendly.

Downside:

• Not suitable for bi-directional communication.
• Some browsers (particularly older versions of IE) don’t fully support SSE.

Best for: Real-time updates where the client only needs to receive data, such as live scores, notifications, and our payment status example.

SSE in Action: Real-Time Payment Status with Next.js

Let’s get to the heart of the matter. I built a simple Next.js app to simulate a real-time payment process using Server-Sent Events (SSE). It demonstrates exactly how you can set up one-way communication to check the status of a payment and notify the user when the payment succeeds or fails.

It's a bit of a headache to set it up for Next since it works a bit differently than plain js so you can thank me later!

Here’s the setup:

Frontend: Transaction Control Component

In the following component, we have a simple UI displaying buttons to simulate different types of transactions that would come from an actual gateway API (Pix, Stripe, and a failing credit card payment). These buttons trigger real-time payment status updates through SSE.

Here’s where the SSE magic happens. When a payment is simulated, the client opens an SSE connection to listen for updates from the server. It handles different statuses like pending, in transit, paid, and failed.

"use client";

import { useState } from "react";
import { PAYMENT_STATUSES } from "../utils/payment-statuses";

const paymentButtons = [
  {
    id: "pix",
    label: "Simulate payment with Pix",
    bg: "bg-green-200",
    success: true,
  },
  {
    id: "stripe",
    label: "Simulate payment with Stripe",
    bg: "bg-blue-200",
    success: true,
  },
  {
    id: "credit",
    label: "Simulate failing payment",
    bg: "bg-red-200",
    success: false,
  },
];

type transaction = {
  type: string;
  amount: number;
  success: boolean;
};

const DOMAIN_URL = process.env.NEXT_PUBLIC_DOMAIN_URL;

export function TransactionControl() {
  const [status, setStatus] = useState<string>("");
  const [isProcessing, setIsProcessing] = useState<boolean>(false);

  async function handleTransaction({ type, amount, success }: transaction) {
    setIsProcessing(true);
    setStatus("Payment is in progress...");

    const eventSource = new EventSource(
      `${DOMAIN_URL}/payment?type=${type}&amount=${amount}&success=${success}`
    );

    eventSource.onmessage = (e) => {
      const data = JSON.parse(e.data);
      const { status } = data;

      console.log(data);

      switch (status) {
        case PAYMENT_STATUSES.PENDING:
          setStatus("Payment is in progress...");
          break;
        case PAYMENT_STATUSES.IN_TRANSIT:
          setStatus("Payment is in transit...");
          break;
        case PAYMENT_STATUSES.PAID:
          setIsProcessing(false);
          setStatus("Payment completed!");
          eventSource.close();
          break;
        case PAYMENT_STATUSES.CANCELED:
          setIsProcessing(false);
          setStatus("Payment failed!");
          eventSource.close();
          break;
        default:
          setStatus("");
          setIsProcessing(false);
          eventSource.close();
          break;
      }
    };
  }

  return (
    <div>
      <div className="flex flex-col gap-3">
        {paymentButtons.map(({ id, label, bg, success }) => (
          <button
            key={id}
            className={`${bg} text-background rounded-full font-medium py-2 px-4
            disabled:brightness-50 disabled:opacity-50`}
            onClick={() =>
              handleTransaction({ type: id, amount: 101, success })
            }
            disabled={isProcessing}
          >
            {label}
          </button>
        ))}
      </div>

      {status && <div className="mt-4 text-lg font-medium">{status}</div>}
    </div>
  );
}

Backend: SSE Implementation in Next.js

On the server side, we simulate a payment process by sending periodic status updates through SSE. As the transaction progresses, the client will receive updates on whether the payment is still pending, has been completed, or has failed.

import { NextRequest, NextResponse } from "next/server";

import { PAYMENT_STATUSES } from "../utils/payment-statuses";

export const runtime = "edge";
export const dynamic = "force-dynamic";

// eslint-disable-next-line @typescript-eslint/no-unused-vars
export async function GET(req: NextRequest, res: NextResponse) {
  const { searchParams } = new URL(req.url as string);
  const type = searchParams.get("type") || null;
  const amount = parseFloat(searchParams.get("amount") || "0");
  const success = searchParams.get("success") === "true";

  if (!type || amount < 0) {
    return new Response(JSON.stringify({ error: "invalid transaction" }), {
      status: 400,
      headers: {
        "Content-Type": "application/json",
      },
    });
  }
  const responseStream = new TransformStream();
  const writer = responseStream.writable.getWriter();
  const encoder = new TextEncoder();
  let closed = false;

  function sendStatus(status: string) {
    writer.write(
      encoder.encode(`data: ${JSON.stringify({ status, type, amount })}\n\n`)
    );
  }

  // Payment gateway simulation
  async function processTransaction() {
    sendStatus(PAYMENT_STATUSES.PENDING);

    function simulateSuccess() {
      setTimeout(() => {
        if (!closed) {
          sendStatus(PAYMENT_STATUSES.IN_TRANSIT);
        }
      }, 3000);

      setTimeout(() => {
        if (!closed) {
          sendStatus(PAYMENT_STATUSES.PAID);

          // Close the stream and mark closed to prevent further writes
          writer.close();
          closed = true;
        }
      }, 6000);
    }

    function simulateFailure() {
      setTimeout(() => {
        if (!closed) {
          sendStatus(PAYMENT_STATUSES.CANCELED);

          // Close the stream and mark closed to prevent further writes
          writer.close();
          closed = true;
        }
      }, 3000);
    }

    if (success === false) {
      simulateFailure();
      return;
    }

    simulateSuccess();
  }

  await processTransaction();

  // Return the SSE response
  return new Response(responseStream.readable, {
    headers: {
      "Access-Control-Allow-Origin": "*",
      Connection: "keep-alive",
      "X-Accel-Buffering": "no",
      "Content-Type": "text/event-stream; charset=utf-8",
      "Cache-Control": "no-cache, no-transform",
      "Content-Encoding": "none",
    },
  });
}

Also, make sure you add .env.local file with this content:

NEXT_PUBLIC_DOMAIN_URL='http://localhost:3000'

Why SSE Over WebSockets in This Case?

Now that we’ve seen how to implement it, you might be wondering: why use SSE over WebSockets for this? Here’s why:

• Unidirectional Communication: In our scenario, the client only needs to receive updates about the payment status. There’s no need for the client to send data back to the server constantly, so the simplicity of SSE fits perfectly.
• Lightweight: Since SSE uses a single HTTP connection to stream updates, it’s more resource-efficient compared to WebSockets, which maintain full-duplex communication.
• Firewall-Friendly: SSE is easier to work with across different network environments because it runs over HTTP, which is usually open in firewalls, whereas WebSocket connections can sometimes run into issues.
• Browser Support: While not as widely supported as WebSockets, SSE is supported by modern browsers, making it reliable for most use cases where unidirectional data is needed.

Conclusion: Know Your Tools

That interview question turned into an incredible learning experience, opening my eyes to the subtle differences between long polling, short polling, WebSockets, and SSE. Each method has its time and place, and understanding when to use which one is crucial for optimizing real-time communication.

SSE might not be as glamorous as WebSockets, but when it comes to efficient, one-way communication, it's the perfect tool for the job—just like in our e-commerce payment example. Next time you're building something that requires real-time updates, don’t just reach for WebSockets by default—consider SSE for its simplicity and efficiency.

Hope this deep dive into real-time communication techniques keeps you sharp for your next project or that tricky interview question!

Let's get our hands dirty

Next.js + TypeScript example repository: https://github.com/brinobruno/sse-next
Next.js + TypeScript example deployment: https://sse-next-one.vercel.app/

References

here are some authoritative sources and references you could explore for deeper insights:

WebSockets And SSE Documentation:

MDN Web Docs: The WebSockets API
MDN Web Docs: Using Server Sent Events

Next API Routes

Next.js: API Routes

Let's connect

I'll share my relevant socials in case you want to connect:
Github
LinkedIn
Portfolio