What should I do when I don't know how to answer a system design question?

When you do not know how to answer a system design question, slow down and reduce the problem to fundamentals: clarify scope, identify users and core actions, separate reads and writes, estimate scale, choose simple storage, then add complexity only where a requirement forces it. You can still pass an unfamiliar prompt if your reasoning is structured.

The worst move is pretending you know a memorized solution and guessing components.

Use this sequence when you feel stuck:

1. Restate the prompt. "We are designing a service where users can..."
2. Ask scope questions. Identify the top features and what is out of scope.
3. Find the main workload. Is it read-heavy, write-heavy, real-time, media-heavy, financial, geospatial, or analytics-heavy?
4. Start with a simple design. API service plus database is a valid baseline.
5. Add components from pressure. Cache for hot reads. Queue for slow work. Sharding for data volume. CDN for global static/media delivery.
6. Say what you are unsure about. Turn uncertainty into a trade-off.

This framework works because most system design prompts are combinations of familiar pressures. System Design Structure gives the full checklist.

Suppose the interviewer asks you to design a ride-sharing dispatch system and you have never studied it.

Start from first principles:

• Users: riders and drivers
• Core actions: rider requests ride, driver location updates, system matches driver, driver accepts
• Main workload: high-write location updates and low-latency nearby-driver search
• Data: driver state, ride request, location index, trip history

Now the design begins to appear. Frequent driver pings point to High-Write Location Tracking. Nearby search points to Geospatial Indexing. Driver assignment needs atomic reservation so two riders do not get the same driver, which appears in Ride Matching and Dispatch.

Even if you did not know the "Uber design" by memory, you found the hard parts.

Freezing silently. Think out loud. Interviewers can help if they see your reasoning.

Jumping to random technologies. Kafka, Redis, Cassandra, and Kubernetes are not recovery plans. Requirements come first.

Over-apologizing. It is fine to say, "I have not designed this exact system, so I will reason from the core access patterns."

Ignoring simpler baselines. Start with a simple service and database, then add cache, queue, CDN, replicas, or shards only when pressure appears.

Treating unfamiliar domains as impossible. A new domain usually still has reads, writes, state, latency, consistency, and failure modes.

Practice unfamiliarity on purpose. Pick prompts outside your comfort zone:

• Ride-Sharing Service if you usually study CRUD systems
• Distributed Cache if you usually study product apps
• Internal Ledger if you avoid correctness-heavy systems
• Web Crawler if you avoid distributed worker problems

Before reading any solution, write the main workload and the first simple architecture.

Being stuck is not fatal. Staying unstructured is. If you can clarify, simplify, reason from access patterns, and explain trade-offs, you can handle prompts you have never memorized.