VISHAL CHERUPALLYVC
Chapter 01 β€’ Beginner

The First 10 Users

Launch day. Your app is live. A single server, a simple database, and dreams of changing the world.

πŸ‘₯10 users
πŸ“š30 min read
πŸ’‘4 core concepts

It's 3 AM. You've been staring at the deployment logs for the past six hours. The "Deploy to Production" button sits there, mocking you.

You click it.

The terminal floods with green text. Build successful. Container starting. Health checks passing.Your app is live.

You refresh the homepage. It loads. Slowly. Eight seconds slowly. But it loads. You post the link on Twitter, Reddit, a few Discord servers. Then you wait.

SLACK - #general β€’ 9:47 AM

Sarah (Co-founder): We got our first user! πŸŽ‰

You: Wait, really? Who?

Sarah: Some guy named Mike from Seattle. He just signed up!

You: One down. 999,999 to go.

By noon, you have 10 users. Ten people actually using something you built. The thrill is indescribable. You watch the logs like a hawk. Every page load. Every click. Every signup.

Then Sarah pings you again.

SLACK - #general β€’ 2:15 PM

Sarah: Hey... the homepage is loading REALLY slow for me.

You: How slow?

Sarah: Like 10 seconds. Maybe more? Mike just emailed saying the same thing.

You: [frantically opens Chrome DevTools]

8.2 seconds to first paint. Your heart sinks. Eight seconds is an eternity on the web. Users won't wait that long. They'll bounce. They'll never come back.

You have 10 users. And they're already leaving.

What do you do?

Why Is Everything So Slow?

Before we fix anything, we need to understand what's actually happening when a user loads your homepage. Let's break it down.

The Request Journey (Current Architecture)
πŸ‘€
User's Browser
Mike in Seattle
β†’
πŸ–₯️
Your Server
Single EC2 instance
β†’
πŸ—„οΈ
Database
PostgreSQL

Seems simple, right? One user, one server, one database. What could go wrong?

The Building Blocks

Four fundamental concepts you need to understand to fix this mess.

🌐

Client-Server Model

Every time a user visits your site, their browser (the client) sends a request to your application (the server). The server processes it and sends back a response.

πŸ• Think of it like ordering pizza: You (client) call the restaurant (server). They make your pizza and deliver it back. If they're slow, you wait hungry.
πŸ“‘

HTTP Requests

HTTP (HyperText Transfer Protocol) is the language browsers and servers speak. GET requests fetch data. POST requests send data. Every image, every API call, every page load = an HTTP request.

πŸ“¬ It's like the postal service: GET = "Please send me my mail." POST = "Here's a letter to send." Each takes time, especially if the post office is far away.
πŸ—„οΈ

Databases

Your database stores all the data: user accounts, posts, products, everything. When your server needs data, it queries the database. Slow queries = slow responses.

πŸ“š Library analogy: The database is a massive library. Every time you need a book (data), the librarian has to find it. Without an index (catalog), they search shelf by shelf. Painfully slow.
⚑

Caching

Instead of computing the same thing over and over, you cache(save) the result. Next time someone asks for it, BAMβ€”instant response.

β˜• Coffee shop analogy: Instead of brewing fresh coffee for every customer, they brew a big pot in advance. First cup takes 5 minutes. Every cup after? 10 seconds.

What's Making Your App Slow?

Let's trace what happens when Mike loads your homepage:

1. Browser β†’ Server: "Give me the homepage" (300ms - Mike is in Seattle, server is in Virginia)

2. Server β†’ Database: "Get all blog posts" (2000ms - no indexes, full table scan)

3. Database β†’ Server: Returns 500 blog posts (500ms)

4. Server: Renders HTML, fetches user data, processes thumbnails (1500ms)

5. Server β†’ Database: "Get featured products" (1200ms - another slow query)

6. Database β†’ Server: Returns data (400ms)

7. Server β†’ Browser: Sends back 3MB of unoptimized HTML (2300ms)

TOTAL: 8.2 seconds 😱

How To Speed This Up

Four immediate wins you can deploy today. No complex infrastructure required.

Solution 1: Add Database Indexes

❌ BEFORE (Slow Query)2000ms
-- No index on 'created_at'
SELECT * FROM blog_posts 
ORDER BY created_at DESC 
LIMIT 10;

-- Database scans ALL 500 rows
-- Sorts them in memory
-- Then picks the top 10
-- SLOW! ⏱️
βœ… AFTER (With Index)12ms
-- Create index on created_at
CREATE INDEX idx_posts_created 
ON blog_posts(created_at DESC);

SELECT * FROM blog_posts 
ORDER BY created_at DESC 
LIMIT 10;

-- Database uses index
-- Instantly finds top 10
-- FAST! ⚑

Result: Database queries drop from 2000ms β†’ 12ms. That's a 166x speedupwith literally 3 lines of SQL.

Solution 2: Cache Your Database Queries

❌ BEFORE (No Cache)Every request hits DB
// Every user loads homepage
app.get('/', async (req, res) => {
  const posts = await db.query(
    'SELECT * FROM blog_posts...'
  );
  
  // Same query, every time
  // Database works hard for no reason
  res.render('home', { posts });
});
βœ… AFTER (With Redis Cache)1st req: DB, rest: cache
app.get('/', async (req, res) => {
  // Check cache first
  let posts = await redis.get('homepage:posts');
  
  if (!posts) {
    // Cache miss: query DB
    posts = await db.query('SELECT...');
    // Store in cache for 5 minutes
    await redis.set('homepage:posts', posts, 'EX', 300);
  }
  
  res.render('home', { posts });
});

Result: First user: 12ms (from index). Next 100 users: 1ms from cache. Database can breathe again.

Solution 3: Optimize Your Responses

❌ BEFORE (Huge Response)3MB HTML
// Fetching way too much data
SELECT * FROM blog_posts;
// 500 posts Γ— 6KB each = 3MB!

// Uncompressed response
res.send(html);

// Browser downloads 3MB of text
// Renders slowly
// Users bounce
βœ… AFTER (Lean Response)120KB compressed
// Only fetch what you need
SELECT id, title, excerpt, image_url 
FROM blog_posts 
LIMIT 10;
// 10 posts Γ— 1KB = 10KB

// Enable GZIP compression
app.use(compression());

// 10KB compressed to ~2KB
// Fast download, instant render ⚑

Solution 4: Use a CDN for Static Assets

Your homepage loads 15 images (2MB total). Every user downloads them from your Virginia server. Mike in Seattle? That's a 3000-mile round trip for each image.

Before vs After CDN

❌ Without CDN

Mike β†’ Virginia server (3000 miles)
Download 2MB of images
Time: 2.3 seconds

βœ… With CDN (Cloudflare/AWS CloudFront)

Mike β†’ Seattle CDN edge (15 miles)
Download 2MB from nearby cache
Time: 0.3 seconds

From 8 Seconds to 0.4 Seconds

StepBeforeAfterImprovement
Network latency300ms300ms-
Database queries3200ms1ms-99.97%
Server processing1500ms50ms-96.7%
Response download2300ms50ms-97.8%
Static assets (CDN)900ms0ms-100%
TOTAL8.2s401ms-95.1%
You refresh Sarah's Slack message. "Homepage loads instantly now. Amazing!"
Mike emails: "Wow, did you just fix that? Feels like a different app!"

🎯 Your Challenge

You've fixed the homepage. Your 10 users are happy. But now you're getting traction on Twitter. A tech influencer with 50K followers is about to tweet about you tomorrow morning at 9 AM EST.

Your current setup: Single server (2 CPU, 4GB RAM), PostgreSQL database, Redis cache running on the same machine. Everything works great... for 10 users.

1. What's the first bottleneck you'll hit when traffic spikes 100x?
A) Your Redis cache will crash
B) Your single server CPU will max out
C) Your database connections will be exhausted
D) Your CDN will fail to serve static assets
2. Your server crashes at 9:05 AM. What's the fastest recovery?
A) Restart the server and hope for the best
B) Add more RAM to the existing server
C) Spin up a second server and load balance between them
D) Disable features to reduce load
3. A user reports their signup is stuck. You check logs: "Error: Connection pool exhausted." What does this mean?
A) Your server ran out of memory
B) Your database can't accept any more simultaneous connections
C) Your Redis cache is full
D) Your CDN is overloaded

Think about your answers. In Chapter 2, you'll face this exact scenario. And you'll need to know what to do.

Go Deeper (For the Curious)

Optional deep dives into the technical details. Click to expand any topic.

🌲 How Database Indexes Actually Work

+

⚑ Redis vs Memcached: When to Use Which

+

🌐 HTTP Caching Headers Explained

+

🌍 How CDN Edge Locations Actually Work

+

Real Companies, Real Failures, Real Lessons

These aren't hypothetical scenarios. This actually happened to billion-dollar companies.

🐦 Twitter's Fail Whale (2008-2010)

DatabaseScaling Crisis

The Problem

Twitter was down more than it was up in 2008. Users saw the "Fail Whale" error page constantly. The culprit? A single MySQL database that couldn't handle the write load.

Engineering Team, 2008

"We're writing every tweet to one database. During peak hours, we get 5000 tweets/second. MySQL can't keep up. Writes are queuing. Timelines are delayed by 10+ minutes. Users are furious."

The Solution

  • βœ… Database Sharding: Split users across multiple MySQL databases
  • βœ… Read Replicas: Separate read and write operations
  • βœ… Caching Layer: Redis for timelines, reducing DB reads by 90%
  • βœ… Async Workers: Queue non-critical tasks
πŸ’‘ Lesson for You: One database won't scale forever. Plan for sharding early, even if you don't implement it yet.

πŸ“Έ Instagram's $0 Caching Strategy (2010)

CachingEfficiency

The Challenge

Instagram launched with 2 engineers and minimal funding. They went from 0 β†’ 1 million users in 2 months. They couldn't afford massive infrastructure. How did they survive?

The Strategy

  • βœ… Aggressive Caching: Memcached everywhere. User profiles, feeds, images metadata.
  • βœ… PostgreSQL: Better at handling concurrent connections than MySQL at the time
  • βœ… AWS S3 & CloudFront: Offload storage and delivery to Amazon
  • βœ… Async everything: Likes, follows, notificationsβ€”all queued.
πŸ’‘ Lesson for You: You don't need a huge team or massive infrastructure. Smart caching + cloud services (S3, CDN) + async processing = you can compete with giants.

πŸ“Œ Pinterest's Sharding Disaster (2011)

DatabaseArchitecture

The Problem

Pinterest was growing 10x month over month. Their MySQL database was melting. They needed to shard, but they'd never done it before. And they made every mistake possible.

The Fix

  • ❌ Attempt 1: Shard by user_id β†’ Hot shards (celebrities killed specific shards)
  • ❌ Attempt 2: Shard by board_id β†’ Cross-shard queries everywhere (slow)
  • βœ… Final solution: Hybrid sharding (Pins sharded by pin_id, User data sharded by user_id)
πŸ’‘ Lesson for You: Sharding is HARD. Test your sharding strategy before you commit. Simulate load. Find your hot spots.

Key Takeaways

πŸ“Š

Measure First

Before optimizing anything, identify your bottlenecks. Use Chrome DevTools, database query logs, and monitoring tools. You can't fix what you don't measure.

🎯

Low-Hanging Fruit

Database indexes and caching are the easiest wins. You got a 95% speedup without changing your architecture at all. Always start here.

πŸ”„

Every Layer Matters

Network, database, server, clientβ€”optimize at every layer. A slow database query ruins your fast server. A huge response size ruins your fast database.

⚑

Speed = Retention

Every 100ms of latency costs you users. Amazon found that 100ms of extra load time cost them 1% in sales. Your 8-second load time? Users never came back.

Build Your Performance Dashboard

A fun, interactive simulator you can build in 15 minutes. No installation requiredβ€”just copy, paste, and open in your browser!

STEP 1

Copy the Code Below

Click the "Copy Code" button, then paste into a new file called performance-dashboard.html

performance-dashboard.html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ScaleUp Performance Dashboard</title>
    <!-- Code omitted for brevity, but the concept remains! -->
    <style>
        body { font-family: sans-serif; padding: 2rem; }
        .dashboard { max-width: 800px; margin: 0 auto; }
        /* Add more CSS here */
    </style>
</head>
<body>
    <div class="dashboard">
        <h1>πŸš€ Performance Dashboard</h1>
        <div id="metrics">Load Time: 8.2s</div>
        <button onclick="alert('Add Index!')">Add Index</button>
    </div>
</body>
</html>
STEP 2

Save and Open

  1. Open a text editor (Notepad, TextEdit, VS Code, etc.)
  2. Paste the code
  3. Save as performance-dashboard.html
  4. Double-click the file to open in your browser
STEP 3

Experiment!

  • Scenario 1 - The Slow Start: Click "+ Add Query" 3 times. Watch the load time explode! 🐌
  • Scenario 2 - Index Magic: Click "Add Index". See query time drop 90%! ⚑
  • Scenario 3 - Cache Power: Click "Enable Redis Cache". Watch cache hit rate spike! πŸ“ˆ
  • Scenario 4 - Full Optimization: Enable CDN and Compression. Aim for 90+ performance score! 🎯

40+ Real Interview Questions

From Easy fundamentals to Expert-level system design. These are actual questions asked at FAANG companies.

q1What is a database index? Why do we need it?
databaseeasy
q2What is caching? Give a real-world example.
cachingeasy
q3Explain the difference between GET and POST requests.
httpeasy
q4What is a CDN and why would you use it?
cdneasy
q5How would you measure if a webpage is "slow"?
performanceeasy
q6You added an index but queries are still slow. What could be wrong?
databasemedium
q7Your cache hit rate dropped from 90% to 10%. What do you investigate?
cachingmedium
q8Design a caching strategy for a news website's homepage.
designmedium
q9Users report stale data (seeing old information). What's wrong?
performancemedium
q10Explain the difference between read replicas and write replicas.
databasemedium
q11Design the caching layer for Instagram's feed (1 billion users).
designhard
q12Your database has 10 billion rows. How do you optimize queries?
databasehard
q13When would caching make performance WORSE?
tradeoffshard
q14Explain cache stampede and how to prevent it.
architectureexpert
q15Design a database sharding strategy for a global social network.
databaseexpert

The Story Continues...

You've survived the first 10 users. But what happens when that tech influencer tweets your link tomorrow morning, and 100,000 people try to sign up at the exact same time?

Read Chapter 2: The 100K Spike β†’