FastAPI WebSocket development
Live data to the screen, without the screen slowing the system.
Acasa Labs builds realtime services in FastAPI: WebSocket gateways for live dashboards and server-sent events for streaming AI answers. Our trading platform's dashboard gets market state through Redis and a FastAPI WebSocket gateway, throttled per instrument. NoteTube streams chat answers over server-sent events with inactivity timeouts.
The problem
Realtime works in the demo and falls over on Monday morning.
One browser tab on a WebSocket is easy. A few hundred, some on weak mobile connections, some left open overnight, while the system behind them is under load, is not. Without limits, a slow client fills a buffer, the buffer fills memory, and the service meant to show data starts holding up the service that makes it. A realtime service needs a send rate, a buffer size, and a rule for every client that stops reading.
What we build with FastAPI
- 01
WebSocket gateways
Fan-out from Redis to many clients, with throttling per topic and subscription management, isolated from the system that produces the data.
- 02
Streaming AI answers
Server-sent events from the model to the browser or app, with timeouts, and cancellation when the user leaves.
- 03
Live dashboards
Status, prices, counts, and alerts pushed to the screen at a rate a person can actually read.
- 04
Connection hygiene
Heartbeats, inactivity timeouts, reconnects that resume, and auth checked when the socket opens, not only at login.
From production
Realtime in systems we run.
Throttled per instrument
Options trading platformMarket state fans out to the dashboard through Redis and a FastAPI WebSocket gateway, throttled per instrument, so a burst on one contract does not flood every screen.
Drop, do not block
Options trading platformThe publisher feeding the gateway is bounded and drops when full. It never blocks the trading path, and if the gateway dies, trading does not notice.
Streams that close themselves
NoteTubeNoteTube's RAG chat streams over server-sent events with inactivity timeouts, so a dead connection does not keep holding resources on the server.
Timeouts on incoming streams too
Acasa SentinelAcasa Sentinel reads camera streams with bounded timeouts, so a stalled camera returns in seconds instead of wedging a thread. The same rule applies on the way in as on the way out.
Honest trade-offs
When you do not need WebSockets
If data only flows from server to client, server-sent events are simpler: plain HTTP, automatic reconnects, and easy to run behind a proxy. If the screen can be a few seconds old, polling is simpler still. If you are on Supabase already, Supabase Realtime may cover it with no service of your own, as it does for GymFast. We reach for a FastAPI WebSocket gateway when clients send as well as receive, or when the fan-out needs rules of its own.
What we reach for
- FastAPI WebSockets
- Server-sent events
- Redis pub/sub
- Uvicorn, asyncio
- Postgres
- Prometheus, Grafana
Proof
Shipped, not pitched.
01Client work
Options trading platform
Microsecond market-data handling for index options, with risk checks that never sleep.
A private trading platform for index options on an Indian exchange: tick capture, research and backtesting, paper and live execution, and a control dashboard. Built for a client's internal use; details are anonymized.
Trading engine · Realtime gateway · Web dashboard
02Our product
NoteTube
A lecture becomes a study system: chat, flashcards, quizzes, all grounded in the source.
An AI learning platform that turns PDFs, YouTube lectures, recordings, and notes into a structured notebook with grounded chat, spaced-repetition flashcards, and graded quizzes.
Web · iOS · Android · Chrome extension · MCP server
Questions
FastAPI WebSockets questions we get asked.
WebSockets or server-sent events?
Server-sent events when data only goes from server to client, like a streaming AI answer. WebSockets when the client sends too, or changes what it is subscribed to without a new request.
How many connections can a FastAPI WebSocket service hold?
It depends more on message rate and size than on FastAPI. We measure with your traffic, run several instances behind a load balancer, and use Redis so every instance receives every message it needs to forward.
How do you authenticate WebSocket connections?
With a short-lived token checked when the socket opens, and a check again when it expires. Closing the socket on logout matters as much as opening it.
Can you add realtime to our existing FastAPI app?
Yes. Usually as a separate gateway process reading from Redis, so realtime load does not compete with your API for the same workers.
Will streaming answers work in a mobile app?
Yes. Server-sent events are plain HTTP, which mobile networks and React Native handle well, and the client reconnects when the connection drops.
FastAPI WebSocket development
Live data that does not slow the system.
A free 30-minute review of your realtime design or the dashboard you need. You leave with the limits and the architecture we would use.