Design Shazam Song ID

Wayfair asks this one in the high-level design round, and the framing does the heavy lifting. The panelist usually hands you the hard signal-processing part as a black box: assume there is a function that turns a piece of audio into a set of fingerprint hashes. The signal processing is off the table. The system wrapped around that function is the whole interview, and that is where all the scale and cost live.

So read the shape before drawing. There are two jobs here, and they could not be more different. One is ingestion: take the whole catalog, fingerprint every song once, and build an index you can search. That runs rarely and in the background. The other is identify. A phone records ten seconds of a song, and you have to find the one matching track out of tens of millions in a second or two. Thousands of other phones are asking at the same time. Ingestion is a batch problem. Identify is a high-fan-out read problem. Almost everything interesting is on the identify side.

The Wayfair angle

The reported Wayfair loops are consistent about where this round goes. The song-matching algorithm is explicitly a black box. The deep dives land instead on scaling to a very large query rate and on system behavior when traffic peaks on weekends. They ask how to cut cost the rest of the week, how to match trending music better, and about metrics like "songs correctly identified per day, week, and month." Read that as the rubric showing its hand. Spend your minutes on the index fan-out, the peak-versus-steady cost story, and what you would put on a dashboard, not on the DSP. This is the HLD round, distinct from Wayfair's separate low-level design round.