4 questions developers actually get asked about websockets — with clear, practical answers you can use to prepare.
A WebSocket is a long-lived, two-way connection between a browser and a server that stays open after it is created, so either side can send messages at any time without re-connecting. A regular HTTP request is one round trip: the client asks, the server answers, the connection closes. WebSockets are the right choice when you need real-time updates pushed to the user without polling.
Use WebSockets when updates are frequent, latency matters, or data flows in both directions (chat, live dashboards, multiplayer games, AI streaming). Stick with regular HTTP when data changes rarely or the page only needs to load once. Polling at scale wastes bandwidth and adds delay, while WebSockets push the moment something happens.
WebSockets are persistent connections between a browser and a server, used for real-time updates inside an app. Webhooks are one-way HTTP POSTs from one server to another, fired when an event happens (Stripe notifying your backend of a payment). They sound similar but solve different problems: WebSockets are for live user-facing UIs, webhooks are for server-to-server notifications.
Connections drop because of bad Wi-Fi, server restarts, or phones going to sleep, so the client must auto-reconnect. The standard pattern is exponential backoff: wait 1 second, then 2, then 4, up to a cap, before retrying. Also re-subscribe to any rooms or channels and replay any messages the user missed while disconnected.
Want the full concept, analogies, and AI prompts for websockets?
Read the full WebSockets block →