WebSockets

# Overview WebSockets... #flashcard - Works similar to [[HTTP(S)]], but allow servers to send data to client in a standardized way without first receiving a request and allows multiple messages to be passed back and forth over same connection. More concisely, it provides a real-time, bi-directional communication between the client and the server. - A WebSocket connection is set up through the following steps: 1. Client initiates WebSocket handshake over HTTP 2. Connection updates to WebSocket protocol 3. Both client and server can send messages 4. Must be explicitly closed  # Key Considerations Requires real-time data to be worth implementing. Some L7 load balancers support websockets, but support is generally spotty (remember that L7 load balancers aren't guaranteeing we're using the same TCP connection for each incoming request). L4 load balancers will support websockets natively since the same TCP connection is used for each request. Also, you must consider how the servers will send the data to the client. Approaches include: - Pushing via [[Consistent Hashing]] - Pushing via [[Pub-sub]] ## Implementation Patterns ### Websockets with Message Broker #flashcard A common pattern for websockets implementation is to use a [[Message Broker]] (i.e., WebSocket Service) to handle the communication between the client and the server. The backend services communicate with the message broker, so there isn't a need for open connections to individual backend services. This is especially useful in a [[Microservices Architecture]].  ### [[Wire Protocol]] The communication over websockets is described using a wire protocol. # Pros of WebSockets #flashcard - Full-duplex (read and write) communication - Lower latency than HTTP due to reduced overhead (e.g. no headers) - Efficient for frequent messages - Wide browser support  # Cons of WebSockets #flashcard - Adds complexity to a system to manage the connection between clients and the server, which typically isn't supported by standard [[Load Balancer]] and [[Firewall]]s. - Requires special infrastructure - Stateful connections, can make load balancing and scaling more complex - Need to handle reconnection  # Use Cases of WebSockets #flashcard - High-frequency, bi-directional communication, - Messaging services - Gaming - Trading platforms  # Related Topics - #ReadLater [How WebSockets cost us $1M on our AWS bill](https://www.recall.ai/post/how-websockets-cost-us-1m-on-our-aws-bill) --- Items to discuss when using WebSockets in a system design interview: #flashcard - Deployments. When servers are redeployed, we either need to sever all old connections and have them reconnect or have the new servers take over and keep the connections alive. Generally speaking you should prefer the former since it's simpler, but it does have some ramifications on how "persistent" you expect the connection to be. You also need to be able to handle situations where a client needs to reconnect and may have missed updates while they were disconnected. - Balancing load across websocket servers can be more complex. If the connections are truly long-running, we have to "stick with" each allocation decision we made. If we have a load balancer that wants to send a new request to a different server, it can't do that if it would break an existing websocket connection. - Using a "least connections" strategy for the load balancer can help, as well as minimizing the amount of work the WebSocket servers need to do as they process messages. Using the reference architecture above and offloading more intensive processing to other services (which can scale independently) can help.  ---