Traffic Patterns

System Design Is Never “One Size Fits All”

A very important thing to understand first: system design is not a fixed recipe. You cannot just copy one company’s system design and use it for another company. Every company has:

• Its own use case
• Its own working style
• Its own traffic pattern (how and when users come to the app)

Your end goal in system design is always to make your system:

1. Scalable (can handle more users without crashing)
2. Fault-tolerant (doesn’t crash easily)
3. Cost-optimized (doesn’t waste money on resources you don’t need)

Scaling a system is easy if you throw a huge amount of resources at it - but that costs a lot of money. Good system design finds the balance: don’t crash, but also don’t overspend.

Real Example: Netflix vs YouTube vs Hotstar

All three are video streaming platforms. But if you take Netflix’s system design and use it for YouTube, YouTube would crash. If you take YouTube’s design and use it for Netflix, Netflix’s bill would explode. Why? Because their traffic patterns are completely different.

Netflix: Predictable Traffic

Netflix’s traffic is mostly predictable because:

• Netflix decides when new movies/shows launch (not random users).
• A movie launch is planned weeks in advance - there’s a trailer, marketing, etc.
• So Netflix already knows that traffic will spike on launch day.

Because of this, Netflix can pre-scale: they can spin up extra servers (say 30 instead of 10) a day before the launch, just in case there’s a rush.

flowchart LR A[Netflix knows: New movie launches tomorrow] --> B[Pre-warm extra servers today] B --> C[Movie launches - big traffic spike] C --> D[Spike handled smoothly, no crash]

They can also pre-cache (store in advance) the first few minutes of a new movie on their CDN servers (servers spread around the world - more on this in a later note) even before the movie launches. This reduces the direct load on their main servers.

Key point: Netflix’s traffic can be predicted because they control when big events (launches) happen.

YouTube: Unpredictable Traffic

YouTube is very different. Anyone can upload or go live at any moment. For example:

• A big creator suddenly goes live - unannounced.
• A political or world event happens - suddenly many news channels go live at once, and everyone rushes to YouTube.

YouTube cannot predict these events. There’s some predictability (like more traffic during exam season when students watch study content, or lower traffic during festivals), but sudden spikes cannot be planned for exactly.

flowchart LR A[Random event happens] --> B[Random creator goes live] B --> C[Sudden unexpected traffic spike] C --> D[System must react in real time]

This means YouTube’s system design must be much more advanced - built to handle sudden, unexpected spikes without pre-warning, using very fast auto-scaling and smart caching strategies.

Hotstar: A Mix - And a Tricky Story

Hotstar is a bit like Netflix (movies/shows are predictable), but it also does live cricket streaming, which behaves very differently.

Here’s what typically happens:

• Hotstar runs two separate services: one for on-demand movies/shows, and one for live streaming.
• On a normal day (no match), the live-streaming service can be scaled down a lot, since barely anyone uses it.
• But if they know a big cricket match is happening tomorrow, they can predict the spike and pre-scale the live-streaming service (e.g., go from 10 servers to 200 servers) while scaling down the movies service (since fewer people watch movies during a match).

flowchart LR A[Match Day Known in Advance] --> B[Scale UP Live-Streaming Service] A --> C[Scale DOWN Movies Service]

The Spike Pattern During a Live Match

During the match itself, traffic doesn’t stay flat - it spikes and dips constantly:

• Toss happens → spike (everyone checks)
• Boring bowler comes on → traffic dips a bit
• A wicket falls → sudden spike
• A star batsman (like Kohli or Dhoni) comes to bat → big spike
• They get out quickly → dip

Because these ups and downs happen so fast and unpredictably, auto-scaling based on averages doesn’t work well here - by the time your system reacts, the moment might already be over. So companies often just over-provision (keep extra servers running) for the whole duration of the match (e.g., all 200 servers running for the entire match, even during quiet periods), because it’s safer than risking a crash.

A funny but real problem: the 'Back Button' issue

Here’s an interesting real-world gotcha: When a match gets boring, people hit the “back” button on their app. That takes them back to the home screen, which shows the movie/show catalog - and this catalog is powered by a different API/service than the live-streaming one!

So even though your live-streaming service is scaled to handle 24 crore (240 million) viewers, when people hit “back,” ALL of them suddenly hit the “Movies” API at once - causing an unexpected spike on a service you thought was quiet.

Lesson: You must think about all the side-effects of user behavior, not just the obvious traffic pattern. What happens right before and right after the main event matters too.

The Big Lesson

None of these companies figured out their perfect system design on day one. They:

1. Started with something.
2. Monitored how it performed.
3. Learned from crashes and mistakes.
4. Improved and adjusted their system over time.

This is why system design is not something you finish once - it evolves constantly as you understand your users and traffic better.

Even a “Simple” Business Like Amazon Has to Think This Way

Even a company like Amazon can partly predict traffic - for example, they know exactly when “Big Billion Days” (a big sale) starts, so they can pre-scale their servers in advance for that specific day and time.

But the general challenge remains: traditional physical servers are heavy and slow to scale. Spinning up a brand new machine takes time, and managing all these machines (assigning CPU/RAM, IP addresses, registering with the load balancer) has a lot of overhead. This overhead makes companies wonder: should I spend my time managing servers, or writing my actual application code?

This exact question is what led to a new idea: services where you don’t manage the server at all. We’ll cover this in a later note about serverless computing and containers.

For now, in the next note, let’s look at how big applications are structured internally - using microservices, API gateways, and queues.