Work / 04 Government / Public Sector
A government body held thousands of virtual meetings on its intranet and kept records by hand. We built a transcription service that handles 8,000 simultaneous audio channels, with a summary, action points and minutes ready when the meeting ends.
- Client
- Government / Public Sector
- Engagement
- 6 months
- Delivered
- 2024
- Concurrent audio channels8,000
- Transcription accuracy> 95%
- Latency from speech to text< 2 s
- Operating cost−35%
The brief
What they came to us with.
Officials met online throughout the day, and minutes were written afterwards from memory and notes. Records were late, uneven and costly to produce.
The body wanted every meeting transcribed live and turned into a summary, action points and minutes. The service had to cope with a full working day of overlapping meetings.
Constraints
- Thousands of meetings running at the same time
- Under two seconds from speech to text
- Accuracy above 95% on real meeting audio
- Capacity that follows demand, not the peak
Before and after
What actually changed.
From notes written afterwards to a record written alongside.
What we did
How it keeps up with the day.
- 01
Stream audio through a queue, not a server
Each meeting’s audio enters a Kafka stream, and a pool of transcription workers reads it. A busy channel never blocks another, and a failed worker’s audio is picked up by the next one.
Fig. 1 The path of one audio channel to textDiagram - 02
Scale with the working day
Kubernetes autoscaling adds workers as meetings start and removes them as they end. Prometheus and Grafana watch latency and queue depth, so the service scales before people notice a delay.
Fig. 2 Concurrent channels against provisioned capacity over a dayDiagram - 03
Turn the transcript into the record
When a meeting ends, the transcript is condensed into a summary and a list of action points with owners. The minutes are assembled from both, in the format the body already uses.
Fig. 3 From transcript to minutesDiagram
How it ran
How the work was paced.
Proof under load first, because the hard part was volume, not accuracy.
Audio and accuracy trials
Test recognition on real meeting audio.
Streaming and scaling
Kafka, worker pool, Kubernetes autoscaling.
Summaries and minutes
Summary, action points and minutes from the transcript.
Load test and handover
Test at full volume, set up dashboards, document.
Outcome
What it changed.
Measured in load tests at full volume and in live use.
Concurrent audio channels
8,000
Before~1,000After8,000
How measured: Highest number of simultaneous channels held within the latency target in the load test.
Transcription accuracy
> 95%
Before~85%After> 95%
How measured: Word accuracy on a held-out set of real meeting recordings.
Latency from speech to text
< 2 s
Before~6 sAfter< 2 s
How measured: Time from spoken word to its text on screen, at full load.
Operating cost
−35%
BeforeAlways-on peak capacityAfter65% of the previous cost
How measured: Monthly infrastructure cost compared with sizing the service for the daily peak.
Built with
PythonEverything glued together
Apache KafkaStreaming
KubernetesRunning at scale
PrometheusMetrics and alerting
GrafanaMonitoring dashboards
What we would tell the next team
- Volume, not accuracy, was the hard problem, so we load-tested before polishing anything else.
- A queue between audio and workers is what made failures boring.
- Autoscaling paid for itself once we measured how empty the service was at night.
More work
Contact
Book a free 15-minute call to talk through what you are working on.
How we connect
- 01Book a short call
Choose a time that works for you on our calendar.
- 02Discovery call
A short call to understand the problem, the people and the constraints.
- 03Final scope and kickoff
We send a clear scope and cost. Once you agree, we start.
Office
393, WeWork Vijohn Tower, 3rd FloorUdhyog Vihar Phase-4, GurugramHaryana 122016
Follow