Design a Service That Captures Zoom Meeting Recordings and Processes Them at Scale

Design the system that brings meeting data from Zoom into your product and processes it. When a recorded meeting ends, the system must obtain the recording and its metadata, process it into useful outputs such as a transcript and an analysis of the conversation, and make the results available to users of your product. The source names this prompt without describing the discussion, so the scope below is stated as assumptions. ### Constraints and Clarifications - Assume a business-to-business product: an administrator at each customer organization connects the organization's Zoom account once, after which its recorded meetings are captured automatically. - Assume the video platform can notify your system when a recording becomes available and offers an authenticated API for listing meetings and downloading recording files, subject to rate limits whose exact values you should ask about rather than assume. - Processing includes at least speech-to-text transcription with attribution of who said what; further analysis such as summaries, topic detection and search indexing runs on the transcript. - Live processing during the meeting is out of scope unless the interviewer adds it. ### Clarifying Questions - How soon after a meeting ends must results be available? - What volume should the design support: customer organizations, meetings per day, and typical and maximum meeting length? - Which outputs are required at launch: transcript only, or summaries, search and analytics as well? - What consent, retention and data-residency rules apply, for example meetings a customer must never have captured? ### Part 1 — Ingesting recordings reliably Describe how the system learns that a recording exists, fetches it within the platform's rate limits, and stores the raw media, including how it copes with notifications that arrive twice, late or never. ```hint Do not rely on one signal Decide what your system does besides waiting for notifications, and how it recognizes a recording it has already handled. ``` #### What This Part Should Cover - Fast, verified receipt of notifications, decoupled from the heavy work - Idempotent handling keyed on stable recording identifiers - A reconciliation path that finds recordings the notifications missed - Rate limiting, credential management and streaming storage of large files ### Part 2 — Processing pipeline Design the processing stages from raw media to transcript to analysis. Explain how work is scheduled across expensive compute, how failures and retries are handled, and how the archive is reprocessed when a model improves. ```hint Checkpoint the expensive steps Some stages are slow and costly while others are cheap. Think about what you persist between them so that a failure does not repeat finished work. ``` #### What This Part Should Cover - Stages with persisted intermediate outputs and idempotent execution - Scheduling, autoscaling and fairness between customers - Retry, dead-letter and partial-result behavior - Versioned reprocessing of historical data ### Part 3 — Storage, serving and operations Explain where raw media, transcripts and derived data live, how users query them, how customer data is isolated and deleted, and how you monitor the pipeline. ```hint Deletion reaches everything A deletion request must remove every copy, including derived outputs and search indexes, not just the original file. ``` #### What This Part Should Cover - Storage choices for media, metadata, text and search - Tenant isolation and access control on every read path - Retention and deletion that propagate to all derived data - Pipeline health metrics and cost visibility ### What a Strong Answer Covers - Back-of-envelope sizing for media storage and transcription compute - Exactly-once outcomes built from at-least-once delivery and idempotent stages - Graceful handling of external-platform failures, expired credentials and missing notifications - Fair scheduling, so that one customer's backlog cannot starve the others - Privacy, consent and deletion treated as first-class requirements ### Follow-up Questions - How would you add near-real-time processing while the meeting is still in progress? - A large customer connects and asks to import two years of past recordings. How do you protect everyone else's freshness? - The transcription model is upgraded. How do you reprocess the archive safely and switch users over? - How would you add a second video platform with a different API?