LiveCap
A production-deployed Vietnamese-English meeting caption system with real-time audio streaming, bilingual transcription, transcript export, and cost-aware AWS infrastructure.
Problem
Bilingual conversations are difficult to follow when captions arrive late, lose speaker context, or require raw meeting audio to be retained. LiveCap needed to keep the interaction real-time while controlling privacy, reliability, and cloud cost.
Users
Vietnamese-English meeting participants who need a readable shared caption workspace in the browser.
My role
Product, architecture, frontend, backend, and AWS infrastructure
Product evidence
Screens captured from the deployed product and its verified architecture documentation.
System path
The system is described as a sequence of responsibilities, not a list of frameworks.
01
Browser
Microphone capture, caption workspace, HTTPS and WSS
02
CloudFront
Single public entrypoint, WAF, private frontend delivery
03
ALB + Fargate
FastAPI, WebSocket sessions, wake and idle scaling
04
AWS AI
Parallel Transcribe streams and finalized-text translation
05
Private storage
Expiring transcript downloads and CloudWatch operations
Outcomes
- Streams 16 kHz PCM from the browser over secure WebSocket connections and renders finalized bilingual caption rows.
- Runs behind CloudFront, ALB, WAF, and private ECS Fargate networking with wake-on-demand and scale-to-zero behavior.
- Passes 208 backend tests, 14 frontend tests, production builds, Terraform validation, CI, and secret scanning.
- Exports finalized text to private S3 through time-limited links without storing raw audio.
Technology
Decisions and trade-offs
Keep audio ephemeral
Microphone audio is streamed for processing but never stored. Only finalized transcript text can be exported.
Use a single browser-facing origin
CloudFront serves the frontend and routes API, WebSocket, and wake traffic so the application has one secure public entrypoint.
Trade instant startup for lower idle cost
The backend scales from zero to one task. The UI explains the cold start and polls health instead of hiding the operational trade-off.
Current boundaries
- The first session after an idle period can take 30-60 seconds while Fargate becomes healthy.
- The service intentionally runs at a maximum of one task because active session state remains process-local.
- A live WebSocket session is interrupted if the task is replaced; ECS restores service but not in-flight state.
What I learned
Production readiness is not a single deployment step. It is the alignment of UX, network boundaries, privacy choices, tests, observability, cost controls, and honest documentation of what the system still cannot guarantee.