System Design: Don't Guess, Clarify: A Complete Guide

You’re in a system design interview, and the interviewer says, "Design a URL shortener." Your mind immediately jumps to consistent hashing, a sharding strategy, maybe Redis. Stop right there. That's how you bomb it. The biggest mistake engineers make, both in interviews and on the job, isn't picking the wrong database; it's building the wrong system because they failed to truly clarify requirements. You can’t design a house without knowing if it's for a single person or a family of ten, or if it needs to withstand hurricanes. The same goes for any system.

The Art of the Interrogation

Think of yourself as a detective, not just a builder. Your initial questions set the entire trajectory. Don't just ask "What are the requirements?" That's too broad, too easy for an interviewer to give a vague answer like "It needs to scale." Instead, push for specifics.

For that URL shortener, I'd kick off with:

• "What's the expected QPS for creating new short URLs? And for redirecting existing ones?" This tells me if we're talking about a few thousand requests per second or millions. It dictates whether a simple relational DB will suffice for storage, or if we need a distributed key-value store like Cassandra or DynamoDB.
• "What's the maximum length of the original URL?" Crucial for database schema design and potential storage limits.
• "Are there any geographical considerations? Do redirects need to be fast globally?" This hints at CDN usage or multi-region deployments. If the latency needs to be under 50ms worldwide, that's a very different system than one optimized for a single region.
• "Do short URLs ever expire? Can users customize them?" Expiration means a background cleanup process; customization means handling collisions and potentially user authentication.
• "What's our acceptable error rate for redirects?" If 99.999% uptime is required, that means sophisticated redundancy. If 99% is fine, you might save a ton of engineering effort.

Remember, the interviewer might not have all these answers readily available. They might even say, "Make an assumption." That's your cue to state your assumption clearly ("I'll assume 1000 writes/sec and 10,000 reads/sec, with 99.9% uptime for redirects") and explain why you made it. That shows thoughtfulness.

Peeling Back the Functional Layers

After the initial burst of operational questions, dig into the core features. Don't just list them; probe their implications.

For an "online photo album" system, you wouldn't just note "upload photos." You'd ask:

• "What file formats do we support? Are there size limits per photo?" This impacts storage (S3, GCS) and processing (transcoding services).
• "Do we need to support video? What about live streaming?" Video changes the entire game, introducing complex encoding, content delivery networks, and real-time considerations.
• "What kind of metadata do we store with each photo? EXIF data? User-defined tags?" This affects your database schema and indexing strategy.
• "How do users share photos? Public links? Private albums with specific users?" This directly informs your access control and authorization system. OAuth 2.0 or a simpler token-based approach?
• "Are there requirements for image manipulation? Resizing, filters, watermarks?" This demands image processing pipelines, possibly using services like ImageMagick or dedicated cloud APIs.

Each question here isn't just about collecting information; it's about exposing the hidden complexities and trade-offs. You might discover that "resizing" is a core feature, which immediately pushes you towards a microservices architecture for image processing.

Non-Functional Requirements: The Unsung Heroes

Many engineers jump straight to functional requirements, but non-functional requirements (NFRs) often dictate the system's architecture more profoundly. These are the "ilities"—scalability, reliability, availability, maintainability, security, latency, throughput.

You absolutely need to explicitly ask about these, even if the interviewer gives you a generic "It needs to be scalable."

• "What's our latency target for user-facing operations? Are we talking sub-100ms for read operations, or can some background tasks take longer?" This differentiates between in-memory caches (Redis, Memcached) and slower, disk-based storage.
• "What's the expected growth rate over the next 1-3 years?" Linear growth versus exponential burstiness changes your scaling strategy. Autoscaling groups become more critical with unpredictable traffic.
• "What's our RTO (Recovery Time Objective) and RPO (Recovery Point Objective)?" This isn't just interview jargon; it determines your backup strategy, disaster recovery plans, and multi-region deployments. If you can lose 24 hours of data and be down for 4 hours, that's a much cheaper system than one requiring zero data loss and sub-minute recovery.
• "What are the security requirements? Are we handling PII (Personally Identifiable Information)? PCI compliance?" This impacts encryption, access control, auditing, and even where you host your data. A healthcare application has vastly different security needs than a public blog.

This is where you might make your biggest assumptions if not challenged. Assuming high availability means you're building a redundant, multi-zone, potentially multi-region system from the get-go. If the actual need is much lower, you've over-engineered. This is your "it depends on your situation" moment: a small internal tool might not need the same DR plan as a public-facing e-commerce site.

The Payoff: Focused Design

Clarifying requirements isn't a chore; it's the foundation of a good design. By asking these pointed questions, you don't just extract information; you demonstrate your thought process. You show that you understand the real-world implications of system design choices, not just the theoretical constructs. You're not just drawing boxes; you're designing a solution for a specific problem with specific constraints. This is what separates a good engineer from a great one.

When you clarify thoroughly, your subsequent design becomes naturally structured. You can justify every component, every database choice, every architectural pattern, because it directly addresses a stated requirement. You won't waste time optimizing for 10 million QPS if the actual requirement is 100. That focus saves time, money, and prevents building a system nobody truly needed.

Ready to Ace Your Next Interview?

Practice with AI-powered mock interviews tailored to your target role and company. Start Practicing for Free | Explore Interview Prep