YouTube API Design: Three Core Endpoints with Requests and Responses
Company: Google
Role: Product Manager
Category: System Design
Difficulty: medium
Interview Round: Other
Name three API endpoints that YouTube relies on. For each one, explain what it does, what the request and response contain, and why it matters to the product.
```hint Follow a user journey
Walk through what a viewer or a creator does in the app and ask which server call each step needs; picking from different journeys gives you three distinct endpoints.
```
### Clarifying Questions
- By endpoint, do you mean HTTP API calls the YouTube apps make to the backend, or does streaming the video itself from the delivery network count too?
- Should I describe the public developer API, or the API that YouTube's own apps would need?
- Should the three cover different users, such as a viewer watching, a viewer searching and a creator uploading, or go deep on one journey?
### What a Strong Answer Covers
- A clear reading of "endpoint" and a reason for picking these three
- For each endpoint: HTTP method, resource path, key parameters and the shape of the response
- Concerns that differ by endpoint: large uploads, pagination and ranking, caching, authentication and quotas
- How video bytes are delivered separately from the metadata API
- The product link: which features and metrics depend on each endpoint
### Follow-up Questions
- How would the upload endpoint cope with a long video sent from a phone whose connection drops halfway through?
- How would you change these endpoints without breaking older versions of the mobile app?
- What would you log when a video is fetched to support recommendations and creator analytics, and what privacy limits apply?
Overview: A technical product manager question that asks for three API endpoints YouTube depends on. It tests describing each endpoint's purpose, request and response, and reasoning about uploads, search pagination, caching, authentication, quotas and how video streaming differs from metadata calls.