Breakdown: Who is Responsible?

In the vast majority of commercial system designs (web apps, e-commerce, banking, SaaS), the hierarchy of "slowness" is almost always the same.

For a typical application, the ranking of importance (and performance bottleneck) looks like this:

1. Database Queries (The bottleneck)
2. Network Calls (The delay)
3. Code Algorithms (The easy part)

Here is the breakdown of why, including the estimated impact percentages for a standard web application.

---

The Breakdown: Who is Responsible?

1. Database Queries (~60% of Performance Issues)

In 9 out of 10 system design interviews (and real-world outages), the database is the first thing to break.

• Why: Reading data from a hard drive (Disk I/O) is physically slow. Even with SSDs, searching through millions of rows, joining tables, and waiting for "locks" takes millions of CPU cycles.
• The Cost: A bad SQL query can freeze a system for seconds.
• System Design Fix: This is why we use Caching (Redis/Memcached). We try desperately to avoid hitting the database.

2. Network Calls (~30% of Performance Issues)

This is the time it takes for data to travel from Server A to Server B (latency).

• Why: Even if your code is instant, the speed of light is a limit. If your app has "Microservices" where Service A calls Service B, which calls Service C, you are simply waiting for the data to travel wires.
• The Cost: A network call usually takes milliseconds (ms). In CPU time, 1ms is an eternity.
• System Design Fix: This is why we use Batching (sending 100 items in 1 request instead of 100 requests) and CDNs.

3. Algorithms / Code Logic (~10% of Performance Issues)

Unless you are doing AI, Video Processing, or Crypto Mining, your algorithm is rarely the problem.

• Why: Modern CPUs can do billions of calculations per second. A loop that iterates 10,000 times to sum a shopping cart takes microseconds (0.000001 seconds).
• The Cost: Negligible in comparison to waiting for a database.
• System Design Fix: Keep code clean, but don't obsess over micro-optimizations. Focus on readability.

---

The "Scale of Latency" (Why Algo loses)

To understand why Algorithms matter so little compared to Network/DB, look at the time scale differences.

• Let's imagine 1 CPU Cycle = 1 Second.

Action	Actual Time	Relative Time (If 1 cycle = 1 sec)
Algo: Simple Loop / Variable access	~1 nanosecond	1 second
Network: Sending 2KB data over 1Gbps	~20,000 ns	5.5 hours
Network: Packet Round Trip (Ping)	~150,000 ns	1.7 days
Disk/DB: Reading from SSD	~1,000,000 ns	11.5 days
Network: Packet sent from US to Europe	~150,000,000 ns	4.8 years

Conclusion: Optimizing your code to save 5 CPU cycles is useless if your database query takes "11 days" (relative time) to return.

When does the Algorithm become #1?

There are specific cases where the Algorithm becomes the most important factor (80%+ impact):

1. Video Compression/Streaming: (Netflix/YouTube encoding) - Heavy CPU math.
2. High-Frequency Trading: (Stock markets) - Every nanosecond counts; network is optimized via hardware, so code speed wins.
3. Encryption/Hashing: (Blockchain/Crypto) - Pure mathematical processing.
4. AI/ML Inference: Running neural networks is pure matrix multiplication.

Summary

For a standard company system (like an e-commerce store or social network):

• Database (60%): Optimize your SQL, add Indexes, use Redis.
• Network (30%): Reduce the number of calls (Chatty I/O), keep servers close to users.
• Algo (10%): Just avoid obvious mistakes (like nested loops on massive arrays).