What should I do if the interviewer challenges an assumption or calculation?

Never get defensive. Treat it as a collaborative signal. Say: 'That's a fair point. If our write volume is 5x higher than my baseline estimate, our single primary database will become a write bottleneck. Let's look at partitioning our write traffic using consistent hashing across 4 shards.'

How do I decide between Strong Consistency and Eventual Consistency?

Start from the operation's correctness needs. Some payment, inventory, or reservation operations need strong coordination to prevent conflicting updates, while feeds and counters may tolerate delayed propagation. The right choice depends on the data model, failure behavior, and product requirements; explain the trade-off rather than calling one approach mandatory for an entire domain.

How can I practice system design effectively before my interview?

Choose a prompt, write down requirements and assumptions, sketch the data model and request flow, then explain one or two trade-offs aloud. Review where your assumptions changed the design and practice again with a different scale or constraint.

System Design Interview Preparation: A Flexible 45-Minute Framework

Q: Should I draw diagrams using specific cloud vendors (AWS/GCP) or generic primitives?

Start with generic architectural primitives when they help explain the design. Name a vendor-specific service only when it clarifies an implementation choice, and describe the relevant trade-off.

The core trap: Why rushing into architecture fails

System design prompts are open-ended: you may be asked to design a URL shortener, a feed, or a rate limiter. A common mistake is to choose technologies before clarifying what the system needs to do and what constraints matter.

Make your reasoning visible: clarify scope, state assumptions, estimate only the scale that affects a decision, sketch a design, then discuss trade-offs and failure cases. The order and depth should respond to the interviewer's prompt, not a memorized script.

Use the outline below as one practice structure. Interview formats and time limits differ. For related prompts, see InterviewUp's System Design Interview Questions.

A sample pacing plan for a 45-minute system design interview

Use the following as an example for a 45-minute practice round, not a universal interview schedule. Ask about the interviewer’s priorities and adjust the time you spend on each phase:

Phase 1: Scope & Requirements Clarification (Minutes 0–5): Establish core functional features (what the user actually does) and non-functional requirements (high availability vs strong consistency, latency thresholds, read-to-write ratios).
Phase 2: Capacity Estimation & API Contracts (Minutes 5–10): Calculate Queries Per Second (QPS), peak traffic multipliers, storage volume per year, and define clean REST/gRPC endpoints.
Phase 3: High-Level Architecture (Minutes 10–25): Draft the end-to-end request lifecycle: Client -> DNS/CDN -> Load Balancer -> API Gateway -> Stateless Services -> Primary Database & Cache.
Phase 4: Deep Dive & Bottleneck Resolution (Minutes 25–38): Address database sharding, caching strategies (Cache-Aside, Write-Through), message queues for async decoupling, and replication lag.
Phase 5: Trade-offs & Production Observability (Minutes 38–45): Review Single Points of Failure (SPOF), CAP theorem compromises, circuit breakers, rate limiting, and SLA/SLI metrics.

Example milestones for a 45-minute practice round

Phase	Time Target	Primary Goal	Key Deliverable
1. Requirements	Min 0–5	Narrow feature scope & constraints	3 core user flows + availability/consistency target
2. Estimations	Min 5–10	Determine scale & data footprint	Read/Write QPS + 5-year storage estimate + API contracts
3. High-Level Design	Min 10–25	Establish end-to-end request flow	Macro diagram (Client, Gateway, App Services, DB, Cache)
4. Deep Dive	Min 25–38	Solve scaling bottlenecks & storage	Data partitioning, cache eviction, async workers, replication
5. Wrap-Up & Trade-offs	Min 38–45	Defend architectural decisions	Bottlenecks, SPOF mitigation, monitoring, failure recovery

Concrete walkthrough: Designing a distributed URL shortener (TinyURL)

The following URL-shortener walkthrough is an illustrative scenario. Treat its traffic, retention, and latency figures as assumptions to discuss with an interviewer, not as default requirements for every design.

Phase 1: Clarifying Requirements

• *Functional*: Given a long URL, generate a shorter unique alias (e.g., `https://tiny.url/abc1234`). When accessing the short alias, redirect the user via HTTP 301/302 to the original destination. Custom aliases are optional. Links expire after 5 years by default.

• *Non-Functional*: Highly available (99.99%), low redirection latency (<20ms p99), reads heavily outnumber writes (100:1 read-to-write ratio).

Phase 2: Capacity Estimations & Math

• *Traffic*: 100 million new URLs created per month. Write QPS: `100M / (30 days × 86,400s) ≈ 40 writes/sec`. Read QPS (100:1 ratio): `40 × 100 = 4,000 reads/sec`. Peak read traffic: `4,000 × 2 = 8,000 QPS`.

• *Storage*: 100M URLs/month × 12 months × 5 years = 6 billion records. At ~500 bytes per record (long URL, short URL, timestamp, user ID), total 5-year storage requirement is `6B × 500 bytes = 3 Terabytes`.

Cache sizing: Estimate memory from the distinct keys you expect to retain, the entry size including metadata and storage overhead, and the eviction or TTL policy. Request volume alone does not tell you how many unique URLs need to fit in cache.

Phase 3: High-Level Architecture Flow

1. Client sends write request `POST /api/v1/urls { longUrl }` through Route 53 to an API Gateway.

2. The URL Shortener Service generates a 7-character Base62 string (`[0-9a-zA-Z]`, providing `62^7 ≈ 3.5 trillion` unique permutations).

3. To eliminate hash collisions and avoid distributed database locking, use a Key Generation Service (KGS) or pre-allocated sequential range counters from ZooKeeper/etcd.

4. The mapping is written to a distributed NoSQL Key-Value database (DynamoDB or Cassandra) because the data has no relational joins, requires high partition scalability, and primary-key lookups are `O(1)`.

5. Read requests (`GET /abc1234`) check Redis first. On cache hit, return HTTP 302 redirect. On cache miss, fetch from DynamoDB, write to Redis, and redirect.

Use back-of-the-envelope estimates to compare options

Use estimates to compare design options, not to pretend to know exact production values. State assumptions, use round numbers, and revise the estimate if the interviewer changes the traffic, retention, or latency requirements.

Distributed Systems Latency Numbers & Unit Conversions

Operation / Unit	Typical Latency / Scale	Architectural Takeaway
L1 Cache Reference	0.5 – 1 nanosecond	Fastest CPU memory; local computation is free.
RAM Access	100 nanoseconds	In-memory caches (Redis) are ~1,000x faster than disk.
SSD Random Read	100 microseconds (0.1 ms)	Modern NVMe storage; fast but orders of magnitude slower than RAM.
Datacenter Roundtrip	500 microseconds (0.5 ms)	Internal network calls between microservices.
Cross-Country Roundtrip (US)	50 – 100 milliseconds	Why CDNs and edge points of presence (PoPs) are critical for p99 latency.
1 Million Requests / Day	≈ 12 QPS average	A service with 10M daily requests handles only ~120 QPS average.
1 Billion Requests / Day	≈ 11,600 QPS average	Requires load balancing, horizontal pod autoscaling, and database read replicas.

The database and storage decision matrix: SQL vs NoSQL vs Object Storage

Choose storage based on access patterns, consistency needs, data shape, and operational constraints. A database label does not guarantee a particular performance or consistency outcome; explain the requirement your choice serves and the trade-off it introduces.

Database Archetype Selection Matrix

Database Type	Ideal Use Case	Examples	Key Trade-offs
Relational (RDBMS)	Structured data, ACID transactions, complex relational joins (Banking, Order processing).	PostgreSQL, MySQL	Vertical scaling limits; horizontal sharding requires complex application logic.
Key-Value / Cache	Ultra-low latency session stores, rate limiters, lookup tables.	Redis, Memcached, DynamoDB	Limited query flexibility; secondary indexes can be expensive.
Wide-Column	Massive write-heavy timeseries, telemetry, event logs, chat messages.	Apache Cassandra, ScyllaDB	Consistency behavior depends on configuration; query patterns shape data modeling; no relational joins.
Document Store	Semi-structured JSON payloads, catalogs, content management.	MongoDB, Couchbase	Schema evolution and indexes need deliberate management; performance depends on data shape and queries.
Object Storage	Static media files, video blobs, document exports, automated backups.	Amazon S3, Google Cloud Storage	Durable object access, not low-latency transactional row updates; request latency varies by service and region.

Frequently asked questions about system design rounds

Practical guidance on navigating edge cases and unexpected interviewer pushback:

QUICK ANSWERS

Frequently asked questions

Clear guidance on common questions candidates ask about this topic.

Start with generic architectural primitives when they help explain the design. Name a vendor-specific service only when it clarifies an implementation choice, and describe the relevant trade-off.

QUICK RECAP

Key takeaways

Clarify the user problem and constraints before choosing components.
State assumptions and estimate the quantities that affect your design.
Use the interview's time and follow-up questions to decide where to go deeper.
Explain the trade-offs behind major choices, including failure behavior.