Design Voice Assistant

Problem Statement: Alexa-Class Voice Assistant

An Alexa-class assistant is four systems wearing one trench coat: an always-listening edge device, a cloud speech pipeline (ASR → NLU → dialog → TTS), a third-party skills ecosystem, and a smart-home control plane. The design tension is that the first must be cheap, private, and always-on, while the second must be accurate, low-latency, and globally scaled — and they meet at a single wake word.

The shape of one request

The device runs a tiny wake-word model locally on a rolling audio ring buffer; nothing leaves the home until that model fires. On wake, the device opens an uplink and streams audio to cloud ASR (speech → text), which feeds NLU (text → intent + slots), which routes to a skill (first-party or third-party webhook), whose reply is spoken back via TTS. The loop has a hard, human-perceptible budget: roughly ASR 600 ms + NLU 120 ms + skill 800 ms + TTS 280 ms ≈ under two seconds end to end, or the assistant feels broken.

Scale and the privacy invariant

Anchor the numbers: ~100M daily active devices, ~800M utterances/day (~9K/s average, ~4× at dinner-time peaks). Two invariants drive the architecture. First, dialog context is AP (a fast session cache; lossy is survivable) while skill billing and account links are CP (must be exact). Second — the one interviewers reward — mute is hardware-enforced: a muted microphone physically cannot open a TLS uplink. Privacy here is a circuit, not a software honor system.

Failure stories that prove you understand the domain

Name the real outages, not happy paths: a false wake triggered by dialogue on the TV, a skill webhook timing out mid-conversation, barge-in where the user interrupts and the TTS buffer must cancel instantly, a child profile that must block commerce intents, and a regional ASR outage that should degrade to a graceful "I'm having trouble" prompt rather than hang.