WebSockets Posts

For two years, the answer to "can I put my WebSocket backend in a private subnet behind CloudFront?" was a flat no. You could shield a REST API, a static site, or a server-rendered app behind CloudFront VPC origins and keep the load balancer entirely off the public internet. But the moment a client tried to upgrade an HTTP connection to a WebSocket, the handshake failed. People discovered this the hard way: a clean wss:// request would come back as a 502, and AWS Support would confirm the limitation in writing. The workaround was always the same retreat: make the load balancer public again, bolt on a WAF, and accept the larger attack surface as the cost of doing real-time business.

Every enterprise wants an AI chatbot now. Most of the tutorials out there will get you a working prototype in an afternoon. Deploying that prototype to production for a Fortune 500 client with 10,000 concurrent users, strict data isolation requirements, and a CFO watching the LLM API bill? That is a different engineering problem entirely. I have built and operated chatbot systems at this scale across regulated industries (healthcare, financial services, government), and the gap between "it works on my laptop" and "it handles production load without bleeding money" is enormous. This article covers the architecture I have landed on after iterating through several generations of enterprise chatbot deployments: React on the frontend, FastAPI on the backend, WebSockets for real-time communication, and a layered storage and caching strategy that keeps costs sane.