Design a Real-Time Lyrics Sync Overlay

Problem statement

Design a real-time lyrics overlay for a music streaming service: as a track plays, the correct line scrolls into view and highlights in time with the audio, optionally word-by-word in karaoke style, optionally with a user-selected translation. The overlay must stay aligned with what the user actually hears across wired headphones, phone speakers, Bluetooth headsets, and cast devices, and it must scale to a full catalog with hundreds of millions of daily streams.

The first move that separates strong answers from weak ones is recognizing what this system is NOT. It is not a real-time communication problem. No server pushes lyric frames to the client at playback time. A synced lyrics document is a static, versioned, time-coded asset: an ordered list of lines (and optionally words) with start and end timestamps. The client fetches that asset once, caches it, and then renders it locally as a pure function of the playback position: activeLine = f(audioPosition). The hard engineering sits in three other places: reconstructing the audible clock on heterogeneous devices, building and maintaining a catalog of accurately time-coded lyrics at scale, and governing licensed delivery across territories.

Why the problem is distinctive

First, audio output latency varies wildly by route. A wired headset adds roughly 20-60 ms of render latency; Bluetooth A2DP with AAC typically adds 150-250 ms; cast and multi-room playback can add 100 ms to over a second of buffering. If the overlay follows the wall clock or the decode position instead of the audible position, Bluetooth users see lyrics arrive a fifth of a second early, which reads as broken. The sync engine must anchor to the audio render clock and compensate per route.

Second, time-coded lyrics do not exist for most of the world's catalog by default. Line-level timestamps come from crowdsourced LRC files and partner catalogs; word-level timestamps mostly come from forced-alignment ML pipelines plus human QA. Coverage economics, not bandwidth, dominate this design.

Third, lyrics are licensed print rights content. They are territory-scoped, attribution-required, and revocable. Delivery must support versioned purges and geo-gating without breaking playback.

Public operating baseline

The category is operationally real and large. Spotify reported 678 million monthly active users and 263 million Premium subscribers in its Q4 2024 results, and rolled out real-time synced lyrics globally in November 2021 powered by Musixmatch, later extending the experience with color-synced lyric backgrounds. Apple announced Apple Music Sing in December 2022 with beat-by-beat synced lyrics and adjustable vocals across its catalog of more than 100 million songs. Tencent Music Entertainment reported 573 million online music MAU in Q3 2024, and its QQ Music and WeSing products pioneered per-word karaoke highlighting and pitch scoring in a market where NetEase Cloud Music built a large community translation and correction culture. Musixmatch claims over 100 million monthly active users across its apps and SDK partners and operates the largest catalog of synced lyrics powering multiple major platforms.

For capacity planning this answer designs an assumed service stated explicitly in the next section: 90 million DAU, 1.26 billion streams per day, and a 3x evening peak. Every uncited number in this answer is a labeled design assumption, budget, or target.

The four architectural planes

1. Client sync plane: audio render clock anchoring, latency compensation, lyric timeline resolution, rendering, seek and rate handling. This plane must be fully autonomous once the document is cached.
2. Delivery plane: immutable versioned lyric assets, CDN distribution, conditional fetch, offline packs, territory gating.
3. Editorial plane: ingestion of LRC/TTML/partner feeds, ML forced alignment, QA, translations, corrections, licensing gates, publishing.
4. Telemetry plane: sync-quality sampling, user offset reports, device-class offset learning, catalog error detection.

A strong answer keeps these planes separate: playback never blocks on the delivery plane, delivery never depends on the editorial plane at read time, and the telemetry plane improves the other three without ever sitting in the render loop.