The 7 System Design Problems You Must Know Before Your Interview

Here's a secret that saved me hundreds of hours of preparation: you don't need to study 50 system design problems.

After analyzing interview questions from Google, Meta, Amazon, Netflix, and 20+ other companies, I discovered something surprising. The same 7 problems, or variations of them, appear in 80% of system design interviews.

Why? Because these 7 problems cover all the fundamental patterns:

• Read-heavy vs. write-heavy systems
• Real-time vs. batch processing
• Fan-out strategies
• Geospatial indexing
• Media processing
• Rate limiting and infrastructure
• Strong vs. eventual consistency

Master these 7, and you can handle any curveball an interviewer throws at you.

Let's dive in.

---

Problem 1: Design a URL Shortener (TinyURL/Bitly)

Why it's essential: This is the "Hello World" of system design. It tests basic architecture skills and appears as a warm-up question in many interviews.

The scenario: Design a service where users submit long URLs and receive short ones (e.g., bit.ly/abc123). When someone visits the short URL, they're redirected to the original.

Key Requirements to Clarify

• Scale: 100M URLs created per day, 10B redirects per day
• Read:Write ratio: 100:1 (redirects vs. creations)
• URL length: As short as possible (6-8 characters)
• Expiration: Never, unless user specifies TTL

High-Level Design

┌─────────┐     ┌──────────────┐     ┌─────────────┐
│  User   │────▶│ Load Balancer│────▶│ API Servers │
└─────────┘     └──────────────┘     └─────────────┘
                                            │
                      ┌─────────────────────┼─────────────────────┐
                      ▼                     ▼                     ▼
               ┌───────────┐         ┌───────────┐         ┌───────────┐
               │   Cache   │         │ Database  │         │ Analytics │
               │  (Redis)  │         │(Cassandra)│         │  (Kafka)  │
               └───────────┘         └───────────┘         └───────────┘

The Core Challenge: Generating Short URLs

Option 1: Hash the long URL

• MD5/SHA → take first 7 characters
• Problem: Collisions are guaranteed
• Solution: Check for collision, regenerate if needed

Option 2: Pre-generate IDs

• Generate unique IDs in advance using a counter service
• Convert ID to Base62 (a-z, A-Z, 0-9)
• 7 characters = 62^7 = 3.5 trillion unique URLs

Option 3: UUID + encoding

• Generate UUID, encode with Base62
• No coordination needed, but longer URLs

Best approach: Pre-generated IDs with a distributed counter (like Twitter Snowflake). Fast, no collisions, guaranteed uniqueness.

Deep Dive Questions to Expect

1. "How do you handle the same URL being shortened twice?"

   • Option A: Return existing short URL (requires lookup index)
   • Option B: Create new short URL (simpler, uses more storage)

2. "How do you scale the database?"

   • Shard by short URL hash
   • Read replicas for redirect traffic
   • Cache hot URLs in Redis (most URLs follow power law distribution)

3. "How do you prevent abuse?"

   • Rate limiting per user/IP
   • CAPTCHA for anonymous users
   • Block malicious destinations

Pattern This Teaches

Read-heavy systems with simple key-value lookups. The same pattern applies to paste services, link shorteners, and any system where you're storing and retrieving blobs by ID.

---

Problem 2: Design Twitter/X

Why it's essential: This problem introduces the fan-out problem, the most important concept in social media system design. It appears in questions about Instagram, Facebook, LinkedIn, and any feed-based system.

The scenario: Design a system where users post tweets (280 characters), follow other users, and see a home timeline of tweets from people they follow.

Key Requirements to Clarify

• Scale: 500M users, 200M daily active users
• Tweets per day: 500M tweets
• Timeline reads per day: 10B
• Average followers: 200 (but celebrities have millions)

The Core Challenge: Timeline Generation

When User A opens their home timeline, they need to see tweets from everyone they follow, sorted by time (or relevance).

Three approaches:

1. Fan-out on write (Push model)

User posts tweet → Write to all followers' timelines

• ✅ Timeline reads are instant (just read from cache)
• ❌ Celebrity posts are expensive (writing to 10M timelines)
• ❌ Wasted work for inactive users

2. Fan-out on read (Pull model)

User opens timeline → Fetch tweets from all followed users → Merge and sort

• ✅ No wasted work
• ❌ Slow for users following thousands of accounts
• ❌ Expensive at read time

3. Hybrid approach (What Twitter actually does)

Regular users: Fan-out on write
Celebrities (>10K followers): Fan-out on read

• Precompute timelines for regular users
• Merge celebrity tweets at read time
• Best of both worlds

High-Level Design

┌─────────────────────────────────────────────────────────────────┐
│                         Client App                               │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                        API Gateway                               │
└─────────────────────────────────────────────────────────────────┘
          │                   │                      │
          ▼                   ▼                      ▼
   ┌────────────┐     ┌──────────────┐      ┌──────────────┐
   │Tweet Service│     │Timeline Service│     │ User Service │
   └────────────┘     └──────────────┘      └──────────────┘
          │                   │                      │
          ▼                   ▼                      ▼
   ┌────────────┐     ┌──────────────┐      ┌──────────────┐
   │ Tweet Store │     │Timeline Cache │      │ User Store   │
   │ (Cassandra) │     │   (Redis)     │      │ (PostgreSQL) │
   └────────────┘     └──────────────┘      └──────────────┘
          │
          ▼
   ┌────────────┐
   │ Fan-out    │
   │ Workers    │
   └────────────┘

Deep Dive Questions to Expect

1. "How do you handle a celebrity with 50M followers posting?"

   • Don't fan-out for celebrities
   • Mark their tweets as "high-fanout"
   • Merge at read time for their followers

2. "How do you rank the timeline?"

   • Chronological: Simple, just sort by timestamp
   • Ranked: ML model scores relevance (engagement prediction)
   • Store both, let user choose

3. "How do you handle trending topics?"

   • Stream processing (Kafka + Flink) to count hashtags
   • Sliding window counts
   • Filter bots and spam

Pattern This Teaches

Fan-out strategies for social graphs. Any time you have a "producer with many consumers" pattern, you'll choose between push, pull, or hybrid. This applies to news feeds, notification systems, and activity streams.

---

Problem 3: Design WhatsApp/Messenger

Why it's essential: This tests real-time systems, delivery guarantees, and connection management, skills that apply to any chat, gaming, or collaborative application.

The scenario: Design a messaging system supporting one-on-one chats, group chats (up to 500 members), read receipts, and offline message delivery.

Key Requirements to Clarify

• Scale: 2B users, 100B messages per day
• Latency: Messages delivered in < 100ms when online
• Reliability: Messages must never be lost
• Security: End-to-end encryption

The Core Challenge: Real-Time Delivery

How do you push messages to users instantly?

WebSocket connections:

• Each online user maintains a persistent WebSocket connection
• Server pushes messages through this connection
• Challenge: Managing millions of concurrent connections

Connection architecture:

┌─────────┐     ┌────────────────┐     ┌─────────────────┐
│ Client  │◀───▶│ WebSocket      │◀───▶│ Message Service │
│  App    │     │ Gateway        │     │                 │
└─────────┘     └────────────────┘     └─────────────────┘
                       │
                       ▼
               ┌───────────────┐
               │ Connection    │
               │ Registry      │
               │ (Redis)       │
               └───────────────┘

High-Level Design

┌─────────────────────────────────────────────────────────────────┐
│                       Client Devices                             │
└─────────────────────────────────────────────────────────────────┘
                              │
                    WebSocket Connections
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    WebSocket Gateway Fleet                       │
│           (Handles millions of persistent connections)           │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                      Message Service                             │
│         (Routing, storage, delivery confirmation)                │
└─────────────────────────────────────────────────────────────────┘
          │                   │                      │
          ▼                   ▼                      ▼
   ┌────────────┐     ┌──────────────┐      ┌──────────────┐
   │ Message DB │     │ Offline Queue │      │ Push Service │
   │ (Cassandra)│     │   (Kafka)     │      │  (FCM/APNS)  │
   └────────────┘     └──────────────┘      └──────────────┘

Delivery Guarantees

Messages go through states: Sent → Delivered → Read

Ensuring at-least-once delivery:

1. Client sends message to server, gets acknowledgment
2. Server persists message, sends to recipient
3. Recipient acknowledges, server marks delivered
4. If no ack, message goes to offline queue
5. On reconnect, deliver from queue

Handling offline users:

• Store messages in persistent queue (Kafka)
• When user reconnects, deliver all pending messages
• Push notification to wake up the app

Deep Dive Questions to Expect

1. "How do you handle message ordering?"

   • Each conversation has a sequence number
   • Server assigns sequence on receipt
   • Client displays in sequence order, even if received out of order

2. "How do you scale WebSocket connections?"

   • Each gateway server handles ~100K connections
   • Horizontal scaling: more servers
   • Connection registry tracks which server has which user

3. "How do you implement end-to-end encryption?"

   • Signal Protocol (same as WhatsApp)
   • Key exchange during setup
   • Server never sees plaintext, only routes encrypted blobs

Pattern This Teaches

Real-time bidirectional communication. The same patterns apply to multiplayer games, collaborative editing, live dashboards, and any system requiring instant updates.

---

Problem 4: Design YouTube/Netflix

Why it's essential: This covers media processing pipelines, CDN architecture, and handling viral content, common questions for any company dealing with rich media.

The scenario: Design a video streaming platform supporting uploads, transcoding, and playback at global scale.

Key Requirements to Clarify

• Scale: 1B daily active users, 500 hours of video uploaded per minute
• Playback: Support 4K, 1080p, 720p, 480p, 360p
• Latency: Video starts playing in < 2 seconds
• Global: Low latency worldwide

The Core Challenge: The Upload Pipeline

Raw video → Multiple formats → Distributed globally

Transcoding pipeline:

┌─────────┐     ┌──────────┐     ┌───────────┐     ┌─────────────┐
│ Upload  │────▶│ Chunking │────▶│Transcoding│────▶│   Storage   │
│         │     │          │     │  Workers  │     │             │
└─────────┘     └──────────┘     └───────────┘     └─────────────┘
                                       │
                     ┌─────────────────┼─────────────────┐
                     ▼                 ▼                 ▼
              ┌──────────┐      ┌──────────┐      ┌──────────┐
              │  4K/H265 │      │1080p/H264│      │ 480p/VP9 │
              └──────────┘      └──────────┘      └──────────┘

Why chunk videos?

• Parallel transcoding (faster)
• Resumable uploads (reliability)
• Adaptive streaming (switch quality mid-playback)

CDN Architecture

┌─────────────────────────────────────────────────────────────────┐
│                         Origin Server                            │
│                    (S3 or GCS - All videos)                      │
└─────────────────────────────────────────────────────────────────┘
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
       ┌───────────┐   ┌───────────┐   ┌───────────┐
       │ Regional  │   │ Regional  │   │ Regional  │
       │   POP     │   │   POP     │   │   POP     │
       │ (US-East) │   │ (Europe)  │   │  (Asia)   │
       └───────────┘   └───────────┘   └───────────┘
              │               │               │
       ┌──────┴──────┐ ┌──────┴──────┐ ┌──────┴──────┐
       ▼             ▼ ▼             ▼ ▼             ▼
   ┌───────┐    ┌───────┐        ┌───────┐     ┌───────┐
   │ Edge  │    │ Edge  │        │ Edge  │     │ Edge  │
   │Server │    │Server │        │Server │     │Server │
   └───────┘    └───────┘        └───────┘     └───────┘

How it works:

1. User requests video from nearest edge server
2. If cached → serve immediately
3. If not → fetch from regional POP → cache → serve
4. Popular videos get pushed to edges proactively

Adaptive Bitrate Streaming

The client continuously measures bandwidth and switches quality:

Good bandwidth (10 Mbps)  →  4K stream
                          ↘
Bandwidth drops (2 Mbps)  →  720p stream
                          ↘
Bandwidth drops (500 Kbps) → 360p stream

Implementation:

• Video split into 2-10 second segments
• Each segment available in all qualities
• Client requests next segment in appropriate quality
• Protocols: HLS (Apple) or DASH (open standard)

Deep Dive Questions to Expect

1. "How do you handle a video going viral?"

   • Pre-warm CDN caches when video is trending
   • Origin can handle millions of concurrent requests
   • Auto-scale transcoding workers for sudden upload spikes

2. "How do you reduce storage costs?"

   • Tiered storage: hot (SSD), warm (HDD), cold (Glacier)
   • Delete lower-quality versions of unpopular videos
   • Deduplication (same video uploaded twice)

3. "How do you recommend videos?"

   • Collaborative filtering (users who watched X also watched Y)
   • Content-based (similar metadata, audio fingerprints)
   • Real-time signals (watch time, likes, shares)

Pattern This Teaches

Media processing pipelines and CDN architecture. Same patterns apply to image-heavy platforms (Instagram), audio streaming (Spotify), and any global content delivery.

---

Problem 5: Design Uber/Lyft

Why it's essential: This introduces geospatial systems and real-time matching, patterns that appear in any location-based service (DoorDash, Instacart, Google Maps).

The scenario: Design a ride-sharing platform that matches riders with nearby drivers in real-time.

Key Requirements to Clarify

• Scale: 50M riders, 5M drivers, 20M rides per day
• Matching latency: < 1 second to find a driver
• Location updates: Drivers send location every 3 seconds
• Global: Different cities have different driver densities

The Core Challenge: Geospatial Indexing

How do you efficiently answer: "Find all drivers within 5km of this rider"?

Option 1: Geohash

• Divide world into grid cells with string IDs
• "9q8yyk" = specific area in San Francisco
• Nearby locations share prefix
• Range query: find all drivers with geohash starting with "9q8yy"

Option 2: QuadTree

• Recursively divide space into quadrants
• Subdivide dense areas, keep sparse areas large
• Good for uneven distributions (lots of drivers in Manhattan, few in rural areas)

Option 3: S2 Geometry (what Uber uses)

• Hierarchical decomposition of sphere
• Better than geohash at poles
• Efficient range queries

High-Level Design

┌─────────────────────────────────────────────────────────────────┐
│                    Driver/Rider Apps                             │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                        API Gateway                               │
└─────────────────────────────────────────────────────────────────┘
          │                   │                      │
          ▼                   ▼                      ▼
   ┌────────────┐     ┌──────────────┐      ┌──────────────┐
   │ Location   │     │  Matching    │      │   Trip       │
   │  Service   │     │  Service     │      │  Service     │
   └────────────┘     └──────────────┘      └──────────────┘
          │                   │                      │
          ▼                   │                      ▼
   ┌────────────┐             │              ┌──────────────┐
   │ Location   │◀────────────┘              │  Trip DB     │
   │ Index      │                            │ (PostgreSQL) │
   │ (Redis +   │                            └──────────────┘
   │  S2 Cells) │
   └────────────┘

Location Update Flow

Driver app sends location every 3 seconds
                    │
                    ▼
┌─────────────────────────────────────┐
│ Location Service                     │
│ 1. Calculate S2 cell for new location│
│ 2. Update Redis: driver_id → cell   │
│ 3. Update cell index: cell → drivers│
└─────────────────────────────────────┘

Matching Algorithm

When rider requests a ride:

1. Find nearby drivers:

   • Calculate S2 cells within radius
   • Query Redis for drivers in those cells
   • Filter by availability, rating, car type

2. Rank drivers:

   • Distance (closest isn't always best, traffic matters)
   • ETA (calculated with real-time traffic)
   • Driver rating and acceptance rate

3. Send request:

   • Push to top-ranked driver
   • If no response in 10s, try next driver
   • If all decline, expand search radius

Deep Dive Questions to Expect

1. "How do you handle surge pricing?"

   • Real-time supply/demand ratio per cell
   • High demand + low supply = surge multiplier
   • Display price before rider confirms

2. "How do you calculate accurate ETAs?"

   • Historical travel times for route segments
   • Real-time traffic data from driver GPS
   • Machine learning model for prediction

3. "How do you prevent fraud?"

   • GPS spoofing detection
   • Anomaly detection on trip patterns
   • Driver identity verification

Pattern This Teaches

Geospatial indexing and real-time matching. Same patterns apply to food delivery, dating apps, real-time gaming, and any location-based marketplace.

---

Problem 6: Design a Rate Limiter

Why it's essential: Rate limiting is a building block inside almost every system. Understanding it shows you can think about infrastructure, not just features.

The scenario: Design a distributed rate limiter that enforces limits like "100 requests per minute per user."

Key Requirements to Clarify

• Types of limits: Per user, per IP, per API endpoint
• Limits: 100 requests/minute, 1000 requests/hour
• Distribution: Works across multiple API servers
• Latency: < 1ms overhead per request

Rate Limiting Algorithms

1. Token Bucket (Most Common)

Bucket capacity: 100 tokens
Refill rate: 100 tokens/minute

Each request:
  if bucket has tokens:
    consume 1 token
    allow request
  else:
    reject request (429 Too Many Requests)

• ✅ Allows bursts up to bucket size
• ✅ Smooth rate limiting over time
• ✅ Simple to implement

2. Sliding Window Log

Store timestamp of every request in window
Each request:
  remove timestamps older than window
  if count < limit:
    add current timestamp
    allow request
  else:
    reject request

• ✅ Most accurate
• ❌ Memory intensive (storing all timestamps)

3. Sliding Window Counter

Current window count + (previous window count × overlap percentage)

• ✅ Memory efficient
• ✅ Reasonably accurate
• ⚠️ Slight inaccuracy at window boundaries

Distributed Rate Limiting

The challenge: multiple API servers need to share rate limit state.

Solution: Centralized Counter with Redis

┌─────────┐     ┌─────────┐     ┌─────────┐
│ Server 1│     │ Server 2│     │ Server 3│
└────┬────┘     └────┬────┘     └────┬────┘
     │               │               │
     └───────────────┼───────────────┘
                     │
                     ▼
              ┌─────────────┐
              │    Redis    │
              │             │
              │ user:123 →  │
              │   count: 45 │
              │   expiry: 60s│
              └─────────────┘

Redis implementation (Lua script for atomicity):

local current = redis.call('INCR', key)
if current == 1 then
  redis.call('EXPIRE', key, window_seconds)
end
if current > limit then
  return 0  -- rejected
end
return 1  -- allowed

High-Level Design

┌─────────────────────────────────────────────────────────────────┐
│                         Client                                   │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                      Rate Limiter                                │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ 1. Extract identifier (user ID, IP, API key)             │    │
│  │ 2. Check Redis counter                                   │    │
│  │ 3. If under limit: increment, allow                      │    │
│  │ 4. If over limit: reject with 429 + Retry-After header  │    │
│  └─────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                        API Servers                               │
└─────────────────────────────────────────────────────────────────┘

Deep Dive Questions to Expect

1. "What if Redis goes down?"

   • Local fallback with in-memory rate limiting
   • Accept slightly higher traffic temporarily
   • Or fail closed (reject all) for security-critical limits

2. "How do you handle race conditions?"

   • Redis INCR is atomic
   • For complex logic, use Lua scripts
   • Or Redis Transactions (MULTI/EXEC)

3. "How do you rate limit by API endpoint?"

   • Separate counters: user:123:endpoint:/api/posts
   • Different limits per endpoint
   • Hierarchical limits (global → per-user → per-endpoint)

Pattern This Teaches

Distributed coordination and infrastructure thinking. Rate limiting concepts apply to circuit breakers, load shedding, backpressure, and resource quotas.

---

Problem 7: Design a Notification System

Why it's essential: This covers event-driven architecture, multi-channel delivery, and handling scale with async processing, patterns used in every modern application.

The scenario: Design a system that sends notifications across push, email, SMS, and in-app channels, handling billions of notifications daily.

Key Requirements to Clarify

• Scale: 10B notifications per day
• Channels: Push (iOS, Android), email, SMS, in-app
• Latency: Push notifications < 1 second, email < 1 minute
• Reliability: No notification should be lost
• User preferences: Users can opt out of specific channels/types

High-Level Design

┌─────────────────────────────────────────────────────────────────┐
│                    Event Sources                                 │
│         (Orders, Messages, Alerts, Marketing)                    │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                  Notification Service                            │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ 1. Receive event                                         │    │
│  │ 2. Check user preferences                                │    │
│  │ 3. Render templates                                      │    │
│  │ 4. Route to appropriate channel queues                   │    │
│  └─────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────┘
                              │
         ┌────────────────────┼────────────────────┐
         ▼                    ▼                    ▼
  ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
  │ Push Queue  │     │ Email Queue │     │ SMS Queue   │
  │   (Kafka)   │     │   (Kafka)   │     │   (Kafka)   │
  └─────────────┘     └─────────────┘     └─────────────┘
         │                    │                    │
         ▼                    ▼                    ▼
  ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
  │Push Workers │     │Email Workers│     │ SMS Workers │
  └─────────────┘     └─────────────┘     └─────────────┘
         │                    │                    │
         ▼                    ▼                    ▼
  ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
  │  FCM/APNS   │     │  Sendgrid   │     │   Twilio    │
  └─────────────┘     └─────────────┘     └─────────────┘

Core Components

1. Preference Service

• User notification settings (email on, push off, etc.)
• Quiet hours (no notifications between 10pm-8am)
• Frequency capping (max 5 marketing emails/week)

2. Template Service

• Store notification templates
• Personalization with user data
• Multi-language support

3. Delivery Workers

• Pull from channel-specific queues
• Call external providers (FCM, Twilio, Sendgrid)
• Handle retries and failures

4. Analytics Service

• Track delivery, open, click rates
• A/B testing for notification content
• Feedback loop for optimization

Handling Failures

Notifications must be reliable. Here's the retry strategy:

Initial attempt fails
        │
        ▼
Wait 1 second → Retry #1
        │
        ▼ (if fails)
Wait 5 seconds → Retry #2
        │
        ▼ (if fails)
Wait 30 seconds → Retry #3
        │
        ▼ (if fails)
Move to Dead Letter Queue → Alert on-call

Idempotency: Same notification shouldn't be sent twice

• Generate unique notification ID
• Check before sending (deduplication table)
• External providers often have their own deduplication

Deep Dive Questions to Expect

1. "How do you handle a spike of 1 million notifications?"

   • Queue absorbs the spike
   • Workers auto-scale based on queue depth
   • Priority queues for time-sensitive notifications

2. "How do you prioritize notifications?"

   • Critical (security alerts) > Transactional (order updates) > Marketing
   • Separate queues with different worker allocations
   • Rate limiting for marketing to avoid spam

3. "How do you handle provider failures?"

   • Fallback providers (FCM fails → try APNS)
   • Circuit breaker pattern (stop trying failing provider)
   • Graceful degradation (if push fails, send email)

Pattern This Teaches

Event-driven architecture and multi-channel orchestration. Same patterns apply to payment processing, order fulfillment, workflow engines, and any system with multiple downstream services.

---

The Meta-Pattern: Why These 7 Cover Everything

Each problem teaches a fundamental pattern:

When you get a new question in an interview, map it to these patterns:

• "Design Spotify" → YouTube pattern (media) + Twitter pattern (social/playlists)
• "Design DoorDash" → Uber pattern (geospatial) + Notifications pattern (order updates)
• "Design Google Docs" → WhatsApp pattern (real-time) + new pattern (CRDT/OT)

---

Your Study Plan

Week 1: Deep dive on problems 1-4

• Day 1-2: URL Shortener + Twitter
• Day 3-4: WhatsApp + YouTube
• Day 5: Review and practice explaining

Week 2: Complete the set + practice

• Day 1-2: Uber + Rate Limiter + Notifications
• Day 3-5: Mock interviews with all 7

After mastering these 7, you'll recognize the patterns in any new question. That's the real skill, not memorizing solutions, but seeing the underlying structure.