System Design Interview Help: Frameworks and Real-Time Problem Solving

System Design Interviews Are a Conversation, Not an Exam

The biggest mistake people make in system design interviews is treating them like a test with a correct answer. There isn't one. Interviewers want to see how you think through ambiguity, make tradeoffs, and communicate your reasoning. Two candidates can design completely different systems and both pass — because the evaluation is about the process, not the final architecture.

That said, there are patterns and frameworks that help you structure your thinking. Here are the most commonly asked problems and a practical approach for each.

The Framework: Use This for Every Question

Before diving into specific problems, internalize this four-step approach. It works for virtually any system design question.

• Clarify requirements (3-5 minutes). Ask questions. Functional requirements (what should it do?), non-functional requirements (scale, latency, availability, consistency). Don't assume — interviewers deliberately leave things vague to see if you'll ask.
• Estimate scale (2-3 minutes). How many users? How many requests per second? How much storage? Back-of-envelope math shows you can think quantitatively. 100M users at 10 requests/day = ~12K QPS. That number drives every design decision.
• High-level design (10-15 minutes). Draw the major components — clients, load balancers, application servers, databases, caches, queues. Start simple, then add complexity as needed. Don't jump to microservices for a system that could work as a monolith.
• Deep dive (10-15 minutes). Pick 2-3 areas the interviewer cares about and go deep. Database schema, caching strategy, data partitioning, failure handling. This is where you show real engineering depth.

Problem 1: Design a URL Shortener (like bit.ly)

Key requirements to clarify

How many URLs per day? Do short URLs expire? Custom aliases allowed? Analytics (click tracking)?

Approach

URL generation: Use a base62 encoding of an auto-incrementing ID or a hash-based approach. Base62 gives you 62^7 = 3.5 trillion combinations with 7 characters. If you need guaranteed uniqueness, a counter service (backed by something like ZooKeeper or Redis INCR) works well. If you go with hashing (MD5/SHA256 truncated), you need collision handling.

Storage: A simple key-value store works — short URL maps to long URL plus metadata. For 100M URLs at ~500 bytes each, that's about 50GB. Redis for hot reads, a persistent store (PostgreSQL, DynamoDB) for durability.

Redirection: 301 (permanent redirect, browser caches it) vs 302 (temporary redirect, allows you to track clicks). Most services use 302 because analytics matter.

Scale considerations: Read-heavy workload (100:1 read/write ratio). Cache aggressively. Partition by hash of short URL for horizontal scaling.

Problem 2: Design a Real-Time Chat System (like Slack/WhatsApp)

Key requirements to clarify

1:1 only or group chats? Message history? Read receipts? File sharing? Online status?

Approach

Connection management: WebSockets for real-time bidirectional communication. Each client maintains a persistent connection to a chat server. Use a connection manager to track which user is connected to which server.

Message flow: User A sends a message to server. Server looks up User B's connection (which server they're on). If online, deliver directly via WebSocket. If offline, store in a message queue for later delivery (push notification + store-and-forward).

Storage: Messages in a database partitioned by conversation ID. Use a write-optimized store — Cassandra or HBase for high write throughput. Keep recent messages in cache for fast loading.

Group chat complexity: Fan-out on write (copy message to each recipient's inbox) vs. fan-out on read (recipients fetch from a shared conversation). Small groups: fan-out on write. Large channels (1000+ members): fan-out on read to avoid write amplification.

Online presence: Heartbeat mechanism. User sends periodic heartbeat. If no heartbeat for N seconds, mark offline. Use a distributed cache (Redis) for presence status to avoid querying connection managers directly.

Problem 3: Design a Rate Limiter

Key requirements to clarify

Client-side or server-side? What's being rate limited (API endpoints, users, IPs)? Hard limit or soft limit? Distributed environment?

Approach

Algorithms to know:

• Token bucket: Tokens added at a fixed rate, each request consumes a token. Allows bursts up to bucket size. Most flexible and widely used (used by AWS and Stripe).
• Sliding window log: Store timestamps of each request. Count requests in the window. Accurate but memory-intensive.
• Sliding window counter: Hybrid approach — divide time into slots, use weighted average. Good balance of accuracy and efficiency.
• Fixed window counter: Simple but has edge case at window boundaries where you can get 2x the intended rate.

Distributed rate limiting: The hard part. If you have 10 servers, each tracking counts independently, a user can make 10x the intended limit. Solutions: centralized counter in Redis (INCR + EXPIRE), or accept some imprecision with local counters that sync periodically.

What to return: HTTP 429 Too Many Requests, with headers like X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After. Good API design matters.

Problem 4: Design a Notification System

Key requirements to clarify

Push notifications, email, SMS, or all three? Priority levels? User preferences? Volume?

Approach

Architecture: Event-driven with a message queue at the center. Events (user action, system trigger, scheduled job) go into a queue. Notification service consumes events, checks user preferences, routes to the appropriate channel handler (push, email, SMS).

Deduplication: Critical. Nobody wants five emails about the same thing. Use an idempotency key — hash of (user_id + event_type + entity_id + time_window). Check before sending.

Prioritization: Not all notifications are equal. Security alerts should be immediate. Marketing emails can be batched. Use priority queues or separate queues for different urgency levels.

Template system: Store notification templates in a database. Variable substitution at send time. Allows non-engineers to modify notification content without code deploys.

Delivery tracking: Log every notification attempt with status. Handle retries with exponential backoff for transient failures. Dead letter queue for persistent failures.

Problem 5: Design a News Feed (like Twitter/Facebook)

Key requirements to clarify

Chronological or ranked? How many followers per user (power users)? Real-time updates?

Approach

Fan-out strategies:

• Fan-out on write (push model): When User A posts, immediately write to every follower's feed cache. Fast reads but expensive writes. Works for users with moderate follower counts.
• Fan-out on read (pull model): When User B opens their feed, fetch recent posts from everyone they follow and merge. Cheap writes but slow reads. Better for users with millions of followers.
• Hybrid: Fan-out on write for normal users. Fan-out on read for celebrities (anyone with 10K+ followers). This is roughly what Twitter does.

Storage: Posts in a primary database (sharded by user_id). Feed cache in Redis (sorted set with post IDs, scored by timestamp). Store only post IDs in the cache, fetch full content separately — this keeps the cache lean.

Ranking: If the feed isn't purely chronological, you need a ranking service. Features: recency, engagement (likes/comments), user relationship strength, content type. ML model scores each post. This is where companies like Facebook invest billions.

Common Mistakes to Avoid

• Jumping to the solution immediately. Spend those first 5 minutes on requirements. Interviewers are testing whether you build the right thing, not just whether you can build something.
• Over-engineering. Not every system needs Kafka, Kubernetes, and a microservices architecture. Start simple. Add complexity only when the scale demands it.
• Ignoring tradeoffs. Every design decision has pros and cons. Articulate them. "I chose X over Y because of Z, but the tradeoff is W." This is the single most important thing in system design interviews.
• Not doing back-of-envelope math. "A lot of users" means nothing. "50M DAU generating 500M feed requests per day, which is about 6K QPS with peaks at 3x" — that drives design decisions.

How to Actually Prepare

Read about real systems. Not just design documents — actual engineering blog posts about how companies solved scaling problems. The Uber engineering blog, Netflix tech blog, and Meta engineering blog are goldmines. Understanding why they made certain decisions teaches you more than memorizing patterns.

Practice out loud. System design is as much a communication exercise as a technical one. You need to explain your thinking clearly while drawing diagrams and handling pushback. Craqly's AI interview copilot can help you practice articulating your design decisions in real-time — the kind of back-and-forth you'll face in an actual interview.

Study one system deeply every week rather than skimming ten systems in a day. Understanding the URL shortener problem completely — including edge cases, failure modes, and scaling bottlenecks — is more valuable than having a surface-level understanding of twenty different systems. Start building your system design prep plan with Craqly and get structured practice with real-time feedback.