docs(streaming): document single-server scaling tradeoffs
This commit is contained in:
@@ -141,6 +141,13 @@ Stream realtime events:
|
|||||||
- Client receives `stream:started` when camera accepts.
|
- Client receives `stream:started` when camera accepts.
|
||||||
- Both devices receive `stream:ended` when session is closed.
|
- Both devices receive `stream:ended` when session is closed.
|
||||||
|
|
||||||
|
#### Streaming Scale Tradeoffs (Current Prototype)
|
||||||
|
- The current implementation is **not production-grade at scale**.
|
||||||
|
- Video quality and reliability currently depend on direct browser-to-browser WebRTC success, with a low-fps frame relay fallback in the simulator.
|
||||||
|
- This backend currently acts as a control plane (commands, session state, credentials, events), not a full media plane/SFU.
|
||||||
|
- Running live transport + fan-out + recording on the same web server is possible for small loads but introduces significant CPU, RAM, and network egress pressure under concurrency.
|
||||||
|
- For larger deployments, use a dedicated media plane (managed or self-hosted SFU + recorder) and keep this service focused on auth/session/control APIs.
|
||||||
|
|
||||||
### API Docs
|
### API Docs
|
||||||
OpenAPI docs are generated from Zod/OpenAPI definitions:
|
OpenAPI docs are generated from Zod/OpenAPI definitions:
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user