Design a Song-Recognition Service and High-Volume Ingestion

Design a service that identifies a song from a recording, similar in purpose to Shazam. ### Part 1 — Recognize a recording Explain the core recognition approach, stored catalog representation, request path, and how the service decides whether a match is convincing enough to return. #### What This Part Should Cover - A representation that can match a short recording to part of a catalog track despite ordinary recording noise. - Candidate retrieval followed by verification, with an explicit no-match outcome. ### Part 2 — Handle weekend demand The weekend query volume can reach 100,000 user queries. Clarify the measurement interval and peak rate before sizing the system, then explain how the recognition path would scale. #### What This Part Should Cover - The difference between total query volume, requests per second, and concurrent requests. - Partitioning, replicas, capacity measurements, and overload behavior for fingerprint lookup and candidate verification. ### Part 3 — Add new songs Design the pipeline that adds new tracks to the searchable catalog. Then consider the stated stress case in which this ingestion service receives 100,000 requests per second. #### What This Part Should Cover - Validation, audio processing, indexing, and a clear point when a track becomes searchable. - Idempotent ingestion, queueing, backpressure, and separation from interactive recognition capacity. - Work estimates based on audio bytes, track duration, and fingerprint count rather than request count alone. ### What a Strong Answer Covers - Compatible fingerprint versions across query processing and catalog indexing. - Quality and load evaluation without invented latency or accuracy targets. - A coherent publication and recovery plan when an ingestion stage or index shard fails. ### Follow-up Questions - What happens if only some index shards have received a newly ingested track? - How would you distinguish an unfamiliar song from a noisy recording of a known song?