The Interview Question That Stumped Me: How I Learned to Think at Scale

I thought I had it in the bag.

I'd spent three weeks grinding LeetCode, memorizing sorting algorithms, and practicing whiteboard coding until my hand cramped. When the recruiter scheduled my "system design round" for a senior engineer position, I figured—how hard could it be? I'd been building software for five years. I knew my databases, my APIs, my cloud services.

Then the interviewer asked: "Design Instagram."

I froze.

The Moment Everything Fell Apart

"Just... all of Instagram?" I asked, buying time.

"Sure," she said with a slight smile. "Let's start with the core features. Photo uploads, feeds, followers. How would you build it?"

I did what any panicking engineer would do—I started drawing boxes. A box for the web server. A box for the database. A box labeled "storage" with a question mark. I was designing Instagram like it was my college capstone project that would serve maybe 50 users.

"Okay," the interviewer said gently. "How many users are we talking about?"

"Um... a lot?"

She nodded. "Let's say a billion monthly active users. 500 million daily. 100 million photos uploaded per day."

My carefully drawn boxes suddenly looked ridiculous. One database? For a billion users? I might as well have suggested storing everything in a CSV file.

That's when I realized: I had no idea how to think at scale.

What I Got Wrong (And You Might Too)

Here's the thing about system design interviews—they're not really testing if you can draw boxes and arrows. They're testing if you understand what happens when your neat little architecture meets the real world. The messy, chaotic, billion-user real world.

I made every classic mistake:

I jumped straight to solutions. Before understanding the problem, I was already sketching databases. The interviewer had to pull me back: "What are we actually building? What are the core features? What can we skip for now?"

I forgot about numbers. When you're building a side project, you don't think about capacity planning. But at scale? Everything is about numbers. How many requests per second? How much storage? How much bandwidth? I was designing in a vacuum.

I treated the database like magic. In my mind, databases just... worked. You write to them, you read from them, done. I'd never considered what happens when millions of people try to read from the same database simultaneously. Spoiler: bad things.

The Technical Lessons That Changed How I Think

After bombing that interview (yes, I didn't get the job), I became obsessed with understanding scale. Here's what I learned:

1. Start With Requirements, Not Solutions

The interviewer wasn't being difficult when she asked about features—she was teaching me. Before you design anything, you need to know:

• Functional requirements: What does the system actually do? For Instagram: upload photos, view feeds, follow users, like posts.
• Non-functional requirements: How fast? How reliable? How consistent? Does it matter if your follower count is off by a few for a minute?

These questions aren't pedantic—they completely change your design. A system that needs to be 99.9% available is radically different from one that needs 99.99% availability. That extra 9 costs you millions in infrastructure.

2. Back-of-the-Envelope Math Is Your Friend

When the interviewer threw those numbers at me—100 million photos per day—I should have grabbed them like a lifeline. Instead, I let them float past.

Here's what I should have done:

• 100 million photos/day = ~1,200 photos/second
• Average photo size: 2MB
• Storage needed per day: 200TB
• Storage needed per year: 73 PB

Suddenly, my single "storage box" looked absurd. You can't just throw 73 petabytes at a single server and call it a day. These calculations force you to think about distributed storage, CDNs, and data retention policies.

3. The Database Is Never Just "The Database"

This was my biggest blind spot. I thought: users table, photos table, relationships table, done.

But at scale, you're not using a database—you're using databases (plural), and probably different types:

• Relational database (PostgreSQL) for user accounts and relationships—things that need transactions and consistency
• Object storage (S3) for the actual photos—cheap, durable, scalable
• Cache layer (Redis) for hot data like celebrity profiles that get hammered with requests
• NoSQL database (Cassandra) for the feed—optimized for writes and time-series data

Each piece solves a specific problem. There's no one-size-fits-all.

4. Read-Heavy vs. Write-Heavy Changes Everything

Instagram is read-heavy. For every photo uploaded, it's viewed thousands of times. This insight unlocks your entire architecture.

If it's read-heavy, you:

• Cache aggressively
• Use CDNs to serve content from edge locations
• Denormalize data (yes, duplicate it) to avoid expensive joins
• Pre-compute feeds instead of generating them on-demand

I was designing for writes because that's what I was used to in my CRUD apps. But Instagram's challenge isn't storing photos—it's serving them to a billion people without melting your servers.

5. Consistency Can Wait (Sometimes)

This one blew my mind. In my small-scale world, data was always consistent. If you followed someone, your follower count updated immediately. Period.

But at Instagram's scale? When you post a photo, it doesn't appear in all your followers' feeds instantly. It might take seconds, even minutes. And that's by design.

This is called eventual consistency, and it's a deliberate trade-off. Perfect consistency at scale is expensive and slow. For a social media feed, being a few seconds behind is fine. For a banking transaction? Not so much.

Understanding when you can relax consistency requirements is a superpower.

How I'd Answer That Question Today

If I could go back to that interview, here's how I'd approach it:

First, I'd clarify the scope. "Let's focus on photo uploads and the feed. We'll skip stories, messages, and search for now."

Then, I'd establish scale. "Assuming a billion users, 500 million daily active, 100 million photos per day. Read-heavy system—each photo viewed 1000x on average."

I'd do the math. "That's about 1,200 photo uploads per second, 1.2 million feed reads per second. We need 200TB of storage daily. We're looking at serious scale."

Then I'd design in layers:

1. Client layer: Mobile apps, web app
2. API Gateway: Rate limiting, authentication, routing
3. Application servers: Stateless, horizontally scalable
4. Storage layer: S3 for photos, PostgreSQL for metadata, Redis for caching
5. Feed generation: Pre-computed feeds stored in Cassandra, updated asynchronously
6. CDN: CloudFront or similar for serving photos globally

Finally, I'd talk about trade-offs. "We're choosing availability over consistency for feeds. We're denormalizing data for read performance. We're using a CDN, which costs money but saves on bandwidth and latency."

The Real Lesson

Here's what that failed interview taught me: thinking at scale isn't about knowing every technology or having memorized every AWS service. It's about developing intuition for trade-offs.

Every design decision is a trade-off. Consistency vs. availability. Latency vs. throughput. Cost vs. performance. There are no perfect solutions, only appropriate ones for your specific constraints.

When you're building a side project, you optimize for shipping fast. When you're building for a million users, you optimize for reliability. When you're building for a billion users, you optimize for not going bankrupt on infrastructure costs.

The interviewer wasn't trying to trick me. She was trying to see if I could think through these trade-offs systematically. Could I ask the right questions? Could I justify my decisions? Could I identify bottlenecks before they became disasters?

Your Turn

If you're preparing for system design interviews, here's my advice:

Stop memorizing architectures. You can't memorize your way through "design Twitter" and "design Uber" and "design Netflix." The specifics are always different.

Start thinking in numbers. Every system design problem is a math problem in disguise. How many requests? How much data? How fast? Let the numbers guide your design.

Practice talking through trade-offs. Out loud. To a friend, to a rubber duck, to your cat. "I'm choosing X over Y because..." This is the skill that matters.

Build something at scale. Even if it's just a toy project, try to handle 10,000 requests per second. Watch it break. Fix it. Watch it break differently. You'll learn more from one melted server than from a hundred YouTube tutorials.

That interview question stumped me because I'd never been forced to think beyond my comfortable small-scale world. I'd built features, fixed bugs, shipped code—but I'd never designed for a billion users.

Now I know: the hard part isn't the technology. The hard part is the thinking.

And that's a skill you can learn.

---

Have you been stumped by a system design question? What did you learn? I'd love to hear your story in the comments.