Healthcare · Engineering, no AI
Hospital video streams, load-tested to the browser’s limit
A hospital video monitoring platform was reaching the limits of WebRTC in Chrome. An audit measured the ceiling and a batching fix kept streams stable without disturbing the wards.
- Client
- U.S. HealthTech company, hospital-grade video and computer vision monitoring
- Segment
- Healthcare
- Work
- Audit, load testing, scaling fix
- AI
- Computer vision is the client’s; the work here is the streaming layer
- React
- Chromium WebRTC
- Python microservices
- GStreamer
- Janus
- REST APIs
Before
What was true before
As usage grew, the client’s hospital video monitoring platform hit practical WebRTC limits in Chrome. Performance had to stay stable without disrupting hospital operations.
After
What we did
An audit of the frontend, microservices, GStreamer pipelines and Janus routing, a test harness that simulated hundreds of concurrent streams, staged connection batching, and an observability layer for connection health and stream quality.
Build log
How it was built
- 01
Audited the React frontend, Python microservices, GStreamer pipelines and Janus routing
- 02
Built a test harness that simulated up to 500 concurrent streams
- 03
Profiled Chrome WebRTC under sustained load and measured the connection ceiling
- 04
Implemented staged connection batching and queueing for high-concurrency streams
- 05
Added observability for connection health, stream quality and usage
- 06
Proposed alerting and a roadmap for scaling beyond the local network
Measured
Results
As reported in the published case.
- concurrent streams tested under controlled load
- 500
- entities audited across client systems
- 400+
- week average audit turnaround
- 1
This engagement did not include AI. It is here as evidence of the engineering that AI work sits on.
Engagement
Where this work sits
Next step
Yours would be the next one.
Tell us where it breaks, and you get a written answer on what breaks first and what it costs.