Can you design a system architecture of Netflix?
What the interviewer wants to learn
- Your ability to break a large, real‑world service into logical components.
- How you prioritize scalability, availability, latency, and cost.
- Whether you understand trade‑offs (e.g., consistency vs. performance) and can justify them.
- Your communication style: can you explain complex ideas clearly and iteratively.
How to structure your answer
1. **Clarify requirements** – ask about user load, functional features (streaming, recommendations, auth), non‑functional goals (latency < 100 ms, 99.9 % uptime).
2. **Define high‑level components** – content ingestion, storage, transcoding, CDN, user service, recommendation service, playback service, monitoring.
3. **Detail data flow** – show how a request moves from the client through API gateway, auth, recommendation, and CDN.
4. **Discuss scalability** – sharding, caching layers (Redis, CDN), asynchronous processing (queues), auto‑scaling groups.
5. **Address reliability** – replication, circuit breakers, health checks, graceful degradation.
6. **Touch on monitoring & security** – metrics, logging, rate limiting, TLS, IAM.
7. **Summarize trade‑offs** – e.g., edge caching reduces latency but adds cache‑invalidation complexity.
Example answer
“Sure, let’s start by clarifying what we need to support. I’ll assume we have millions of concurrent viewers, need sub‑second start‑up time, and must deliver 4K video on demand with personalized recommendations. At a high level the system consists of four zones: ingestion, processing, storage, and delivery.
First, creators upload video to an ingestion service behind an API gateway. The file lands in an object store (e.g., S3) and triggers a message on a queue. Workers pull the message, transcode the video into multiple bitrates and segment it for adaptive streaming (HLS/DASH). The segments are then stored back in the object store and replicated across multiple regions.
Metadata – titles, thumbnails, user ratings – lives in a relational DB for strong consistency, while view counts and watch history are stored in a NoSQL store for high write throughput. A recommendation engine reads from the NoSQL store and a graph database to produce a personalized list, cached in Redis.
When a user presses play, the client contacts an auth service, receives a JWT, and calls the playback API. The API looks up the user’s subscription, fetches the recommended list, and returns signed URLs that point to edge CDN nodes. The CDN caches the video segments close to the viewer, giving us low latency and off‑loading traffic from origin storage.
All services are containerized and run in Kubernetes with auto‑scaling based on CPU/memory metrics. Health checks, circuit breakers, and a fallback to a lower‑quality stream ensure high availability. Monitoring is handled by Prometheus and Grafana, while logs go to a centralized ELK stack. Security is enforced via TLS everywhere, IAM roles for service‑to‑service calls, and rate limiting at the gateway.
The main trade‑offs are: using a CDN adds cache‑invalidation complexity but dramatically reduces latency; sharding the metadata DB improves write scalability but requires careful cross‑shard joins for analytics. Overall this architecture meets the functional and non‑functional goals while remaining extensible for future features.”
Mistakes to avoid
- **Jumping straight into a diagram** without first confirming scope and constraints.
- **Listing every possible technology**; focus on why you choose a few key pieces.
- Ignoring **data consistency vs. latency** trade‑offs (e.g., eventual consistency for view counts).
- Forgetting to discuss **failure handling** (replication, fallback paths).
- Over‑engineering the answer with unnecessary details (e.g., low‑level packet routing).
- Speaking in vague buzzwords without concrete examples or justification.