Why HTTP Request-Response Falls Short for Real-Time Features
Traditional HTTP is fundamentally request-driven: the client asks, the server answers, the connection closes. Features that need the server to push updates the moment they happen — a chat message arriving, a live notification, a collaborative document update — do not fit this model naturally. Polling (the client repeatedly asking "anything new?") works as a crude approximation but wastes resources and introduces latency proportional to the polling interval. WebSockets solve this properly by keeping a persistent, bidirectional connection open, letting either side send data at any time without a new request needing to be initiated.
The WebSocket Handshake
A WebSocket connection starts as a normal HTTP request with an Upgrade: websocket header, which the server accepts and upgrades to a persistent socket connection rather than closing after a single response, as a standard HTTP request would:
// client-side
const socket = new WebSocket('wss://yourapp.com/ws');
socket.onmessage = (event) => console.log('Received:', event.data);
socket.send(JSON.stringify({type: 'subscribe', channel: 'notifications'}));PHP's Traditional Limitation, and How It Is Solved
Classic PHP, running under a typical request-per-process or request-per-thread model (PHP-FPM behind Apache or Nginx), is not naturally built to hold long-lived persistent connections the way a WebSocket server needs to. The standard solution is running a dedicated, separate WebSocket server process — using something like Laravel Reverb, Ratchet, or a Node.js-based WebSocket server — alongside your normal PHP-FPM application, with the two communicating through a shared message broker (often Redis) rather than the WebSocket server being the same process handling your regular HTTP requests.
// broadcasting an event from your normal PHP application code
broadcast(new OrderShipped($order))->toOthers();
// the WebSocket server, subscribed to the same Redis channel, receives this
// and pushes it to connected clients subscribed to the relevant channelChannels: Scoping Who Receives What
Broadcasting every message to every connected client does not scale and is usually wrong from a privacy standpoint — a user should only receive updates relevant to them. Channels solve this by letting clients subscribe to specific topics (a specific order's updates, a specific chat room), with the server only pushing messages to clients actually subscribed to the relevant channel:
class OrderShipped implements ShouldBroadcast {
public function broadcastOn() {
return new PrivateChannel('orders.' . $this->order->id);
}
}Private channels additionally require authorization, confirming the requesting user is actually allowed to subscribe to that specific channel — without this check, any connected client could subscribe to any channel name and receive data meant for a different user entirely.
Handling Disconnections and Reconnections Gracefully
Network interruptions, mobile devices switching between WiFi and cellular, and laptops going to sleep all cause WebSocket connections to drop unexpectedly. A production-quality real-time feature needs explicit reconnection logic on the client, ideally with exponential backoff to avoid hammering the server with reconnection attempts, and a strategy for catching up on any messages missed while disconnected — either by re-fetching current state on reconnect, or by replaying missed events from a buffer, depending on how critical it is that no update is ever lost.
Scaling WebSocket Connections
Each open WebSocket connection consumes server memory and a file descriptor for as long as it stays open, which behaves very differently from the short-lived nature of typical HTTP requests. At meaningful scale, a single WebSocket server process becomes a bottleneck, and horizontal scaling requires a shared broker (again, commonly Redis) so a message broadcast from any application server reaches clients connected to any WebSocket server instance, not just the specific instance that happened to handle the originating request.
When Real-Time Is Overkill
Not every feature that feels like it should be "live" actually needs WebSockets — a dashboard that refreshes meaningful data every 30 seconds via simple polling is often genuinely fine, and meaningfully simpler to build and operate than a full WebSocket infrastructure. Reserve WebSockets for cases where the latency of even a short polling interval is actually noticeable and disruptive to the user experience, such as chat, live collaborative editing, or live notifications where users specifically expect instant delivery.
Closing Thought
Real-time features are one of the clearer cases in web development where the right architecture depends heavily on actual user-facing latency requirements, not on what feels technically impressive to build. A simple polling approach is often the right, pragmatic choice; WebSockets earn their added complexity specifically when users genuinely need updates the instant they happen, and that distinction is worth making deliberately rather than defaulting to whichever approach sounds more sophisticated.
Need real-time features built into your PHP application? We can architect and build it properly.
Authentication for WebSocket Connections
A WebSocket connection needs to know who is connecting, the same as any HTTP request does, but the mechanism differs slightly since a WebSocket handshake does not naturally carry cookies or headers the same way every subsequent HTTP request would. A common pattern: the client first authenticates via a normal HTTP request to obtain a short-lived connection token, then presents that token during the WebSocket handshake, which the server validates before allowing the connection and any channel subscriptions to proceed.
$socket = new WebSocket(`wss://yourapp.com/ws?token=${connectionToken}`);Presence Channels: Knowing Who Else Is Connected
Beyond simply receiving broadcast messages, many real-time features need to know who else is currently present (a "user is typing" indicator, a list of currently online collaborators). Presence channels extend the basic channel concept to track and broadcast membership itself — who joined, who left — which requires the WebSocket server to maintain connection state, not just relay messages, adding a meaningful layer of complexity beyond simple broadcast-only channels.
Horizontal Scaling and the Sticky-Connection Problem
Unlike a stateless HTTP request that any server behind a load balancer can handle interchangeably, a WebSocket connection is inherently stateful and tied to whichever specific server instance accepted it. Scaling WebSocket infrastructure horizontally requires either sticky load-balancer routing (ensuring a client's reconnections land on the same server) or, more robustly, a shared pub/sub broker so a message originating from any application server reaches the right client regardless of which specific WebSocket server instance currently holds that client's connection.
Message Ordering and Delivery Guarantees
Real-time systems need an explicit answer to a question easy to overlook: what happens if messages arrive out of order, or if one is lost entirely during a brief disconnect? For features where order and completeness genuinely matter (a collaborative document editor, a financial ticker), messages need sequence numbers and gap-detection logic on the client, prompting a re-sync when a gap is detected, rather than silently assuming the underlying transport delivers everything in order and exactly once, which WebSockets do not guarantee on their own.
Case Study: A Chat Feature That Worked in Testing and Failed at Scale
A community platform launched a real-time chat feature that worked flawlessly in testing with a handful of concurrent users, then degraded badly within hours of a public launch as thousands of users connected simultaneously. The root cause was a single WebSocket server process with no horizontal scaling plan, no shared broker, and connection state held entirely in that one process's memory — exactly the kind of architecture that performs fine at small scale and falls over abruptly once load crosses the single server's capacity, with no graceful degradation in between, just a hard wall the team had not load-tested against in advance. The fix required exactly the shared-broker architecture described earlier in this guide, but retrofitting it under live production pressure was considerably more stressful than designing for horizontal scaling from the start would have been, even though the team correctly judged it unnecessary complexity for their initial, smaller beta launch.
A Glossary for This Topic
WebSocket handshake: the initial HTTP request that upgrades a connection to a persistent, bidirectional WebSocket connection. Channel: a named topic clients subscribe to, used to scope which connected clients receive a given broadcast message. Presence channel: a channel type that additionally tracks and broadcasts which clients are currently connected to it. Pub/sub broker: a message-passing system (commonly Redis) that lets multiple server processes communicate, used to scale WebSocket infrastructure across more than one server instance.
Frequently Asked Questions
Do I need WebSockets for a simple "new message" notification badge? Not necessarily — periodic polling or even just updating the badge on the next full page load is often sufficient unless users specifically expect instant, sub-second delivery.
What happens to a WebSocket connection when a user closes their laptop lid? The connection drops, typically detected by the server through a missed heartbeat/ping, and the client's reconnection logic should handle re-establishing the connection and any necessary state catch-up once the device wakes again.
Can WebSockets work through corporate proxies and firewalls? Generally yes, since WebSockets use the standard HTTP upgrade mechanism over normal ports, but some restrictive corporate networks do block the upgrade specifically, which is worth testing for if your user base includes enterprise environments with locked-down network policies.
Step-by-Step: Adding Real-Time Updates to an Existing Application
Step one: confirm the feature genuinely needs sub-second delivery rather than defaulting to WebSockets for anything that feels like it should be "live" — many cases are well served by simple polling. Step two: if WebSockets are justified, set up a dedicated WebSocket server (Laravel Reverb or equivalent) alongside, not replacing, your normal PHP-FPM application. Step three: design channels around genuine access boundaries from the start, using private channels with explicit authorization for anything user-specific. Step four: build client-side reconnection logic with backoff and a state-catch-up strategy before considering the feature complete, not as a later hardening pass. Step five: load-test the WebSocket server under realistic concurrent-connection volume before a public launch, specifically to catch the kind of hard scaling wall described in the case study above. Step six: add a shared pub/sub broker for horizontal scaling before connection volume actually requires it, since retrofitting this under live load pressure is meaningfully harder than designing for it upfront.
A Comparison Table: Real-Time Approaches at a Glance
Polling: simplest to implement and operate, acceptable latency for many features, wasteful and laggy for genuinely time-sensitive use cases. Server-Sent Events: simpler than full WebSockets for one-way server-to-client updates, not suited to bidirectional communication needs. WebSockets: full bidirectional real-time capability, the most operational complexity, justified specifically when users expect instant, sub-second updates in both directions.
Security Considerations Checklist
Always authenticate WebSocket connections before allowing any channel subscription, never relying on the assumption that knowing a channel name alone is sufficiently private. Validate that private and presence channel authorization checks run server-side on every subscription attempt, not just at initial connection time, since a connection that started authorized for one set of channels should not be assumed authorized for every channel it later attempts to subscribe to. Rate-limit message sending from clients to prevent a single connection from flooding the server or other connected clients with excessive messages. Sanitize any user-generated content broadcast through a channel (a chat message) the same as you would any other user input rendered elsewhere in the application, since real-time delivery does not exempt content from standard XSS risks.
Accessibility Considerations
Real-time updates that change content on screen without any user-initiated action (a live-updating notification list, a chat message appearing) need to be announced appropriately to screen reader users through ARIA live regions, since a purely visual update is otherwise invisible to assistive technology. Avoid overly frequent or noisy live-region announcements, which can overwhelm screen reader users with constant interruptions worse than missing the update entirely — batching or rate-limiting announcements for very high-frequency updates is often the right balance.
How This Plays Out at Different Scales
A small internal tool with a handful of concurrent users can run a single WebSocket server process with no special scaling concerns. A consumer product with thousands of concurrent connections needs the shared-broker horizontal scaling architecture described earlier, ideally built in before launch rather than retrofitted under live load as in the case study above. A very large platform with millions of concurrent connections needs serious capacity planning around connection limits per server, message throughput, and dedicated infrastructure sized specifically for persistent-connection workloads rather than typical short-lived HTTP request patterns.
What to Do When You Inherit a Real-Time Feature Built on Polling Disguised as "Real-Time"
Inheriting a feature marketed internally as real-time but actually implemented as frequent polling (every second or two) is a common, less dramatic but still real performance problem, particularly at scale where many clients polling frequently can generate substantial unnecessary load. Before jumping to a full WebSocket rewrite, measure how much of the perceived "needs to be real-time" requirement is actually about server-push capability versus simply about reducing unnecessary load — sometimes a longer, smarter polling interval (with conditional requests that return quickly when nothing has changed) closes most of the gap far more cheaply than introducing WebSocket infrastructure for a use case that does not strictly require sub-second delivery.
Final Checklist Before Launching a Real-Time Feature
The sub-second latency requirement has been validated against actual user expectations, not assumed. WebSocket connections are authenticated and channel-scoped with proper authorization. Reconnection and state catch-up logic has been tested under realistic network interruption scenarios. The infrastructure has been load-tested at a connection volume meaningfully above expected launch-day traffic. A horizontal scaling path (shared broker) exists even if not yet needed at launch.
Closing Thought, Revisited
Real-time features sit in an unusual category where both under-building (polling disguised as real-time, frustrating users with visible lag) and over-building (full WebSocket infrastructure for a feature that genuinely did not need it) are common, costly mistakes in opposite directions. The right call depends on being honest about actual, validated user-facing latency expectations rather than defaulting to whichever option feels more impressive or more familiar to build.
Choosing Between Self-Hosted and Managed WebSocket Infrastructure
Running your own WebSocket server (Laravel Reverb, Ratchet) gives full control and no per-connection cost from a third party, but puts the scaling and reliability burden entirely on your own team. Managed real-time services (Pusher, Ably) hand that operational burden to a third party at a per-connection cost, which is often a reasonable tradeoff for a smaller team without the dedicated capacity to run and scale WebSocket infrastructure themselves reliably.
Heartbeats and Detecting Dead Connections
A WebSocket connection can appear open at the protocol level while the underlying network path has actually failed silently — a laptop that lost WiFi without a clean disconnect, for instance. Periodic ping/pong heartbeat messages let both sides detect a genuinely dead connection within a bounded time window and clean it up, rather than holding server resources for a connection that will never actually receive a response again.
