How to handle unknown systems

TL;DR

• Every unknown system decomposes into the same four pieces: Users, Data, Operations, and Constraints. Start there every time.
• The two failure modes are freezing (saying nothing) and faking (cargo-culting a memorized design). Both skip the step that actually works.
• Pattern matching is your superpower: a parking garage is an inventory + reservation system, an elevator is a state machine + scheduler, a streaming platform is a CDN + pub-sub pipeline.
• Say it out loud: "I haven't built this exact system, but let me decompose it from first principles." This signals composure, not weakness.
• The universal template (WHO, WHAT data, WHAT operations, HOW MUCH scale, WHAT constraints) works on any prompt an interviewer can throw at you.

---

The Panic Moment

Picture this: you've prepared 15 system design questions. You know URL shorteners, chat systems, and notification pipelines cold. Then the interviewer says, "Design a parking garage management system."

Your brain goes blank. You've never designed a parking garage. You've never even thought about how parking garages work at a technical level. The silence stretches to five seconds, then ten.

I've watched this happen dozens of times in mock interviews. The candidate knows plenty of distributed systems concepts but has no idea how to apply them to something they haven't rehearsed. The problem isn't knowledge. The problem is not having a decomposition framework that works on any prompt.

Here's the honest truth: interviewers at companies like Google and Meta deliberately choose unusual prompts to test exactly this skill. If you can only design systems you've memorized, you'll fail at exactly the companies you want to work at.

---

The Two Failure Modes

When you hit an unfamiliar prompt, candidates fall into one of two traps.

Mode 1: Freezing. You say some version of "I've never used that system, so I'm not sure where to start." Then you wait for the interviewer to rescue you with hints, over-qualifying every statement with "I think maybe..." The interviewer sees no structure, no confidence, and no forward progress.

Mode 2: Faking. You immediately map the unknown system to something you've practiced. "A parking garage is basically like designing Twitter, right?" Then you shoehorn in a design that misses what actually makes the problem unique. The interviewer sees memorization without understanding.

Both modes skip the one step that actually works: decomposing the system from first principles into sub-problems you already know how to solve.

For your interview: if you feel the freeze coming on, say out loud "Let me take 60 seconds to decompose this before sketching." That buys you time and signals structure.

---

The Universal Decomposition Template

Every system, no matter how exotic, answers the same five questions. I call this the WHO-WHAT-HOW framework, and it has never failed me on any prompt.

Here's how to use it in real time:

WHO uses it? List 2-3 user types. For a parking garage: drivers entering/exiting, garage operators monitoring capacity, payment systems processing charges. For an elevator: riders requesting floors, building managers configuring rules.

WHAT data flows? Identify 3-5 core entities and how they relate. Parking garage: spaces, vehicles, sessions (entry/exit events), payments. This takes 30 seconds and gives you your data model.

WHAT operations? Separate reads from writes from events. Parking garage writes: vehicle enters (assign space), vehicle exits (calculate charge). Reads: "is there space available?" Events: space freed, payment processed.

HOW MUCH scale? Ask the interviewer. "Are we designing for a single garage or a chain of 500 garages?" This single question changes everything about your architecture.

WHAT constraints? What makes this system special? Parking garage: real-time capacity tracking (can't oversell spaces), payment must be accurate, entry/exit must be fast (you can't block the gate for 2 seconds while a database query runs).

My recommendation: write these five questions on the whiteboard before sketching any boxes. It takes 90 seconds and prevents 15 minutes of wandering.

---

The Analogy Bridge: Connecting Unknown to Known

Here's where preparation pays off even for systems you've never seen. Almost every system design problem maps to patterns you already know. The skill isn't memorizing systems. It's recognizing which patterns appear inside unfamiliar systems.

The pattern mapping works like this:

• Parking garage = inventory management (spaces are SKUs) + reservation (holding a space) + payment processing. You've probably designed e-commerce inventory before. Same problem, different noun.
• Elevator system = state machine (each elevator has states: idle, moving-up, moving-down, doors-open) + scheduling algorithm (which elevator handles which request). If you've designed a task scheduler or order state machine, you've solved the core problem.
• Live streaming platform = media ingest pipeline + CDN fan-out (1 streamer to N viewers) + real-time chat (WebSocket pub-sub). Each piece is a pattern you recognize independently.
• Voting/polling system = atomic counter + deduplication (one vote per user) + rate limiting. It's a write-heavy system with an idempotency constraint.

I've seen candidates who practiced this analogy bridge technique handle prompts like "Design a smart thermostat network" or "Design an airport baggage tracking system" without any prior preparation on those specific topics. The trick is recognizing the building blocks inside the unfamiliar wrapper.

---

Worked Example 1: Live Streaming Platform (Twitch)

Let's walk through the full decomposition on a prompt you probably haven't practiced: "Design a live streaming platform like Twitch."

Step 1: WHO uses it?

• Streamers: broadcast live video and interact with chat
• Viewers: watch streams with low latency, participate in chat
• Moderators: manage chat, ban users

Step 2: WHAT data flows?

• Streams (metadata: title, streamer, category, viewer count)
• Video segments (the actual media, chunked into small pieces)
• Chat messages (text, sender, timestamp, per-stream)
• User profiles and follow relationships

Step 3: WHAT operations?

Step 4: HOW MUCH scale? Ask: "Are we targeting a Twitch-scale platform with millions of concurrent viewers, or a smaller niche streaming service?" This determines whether you need a global CDN or a simpler media server.

Step 5: WHAT constraints?

• Video latency under 5-10 seconds (viewers expect near-real-time)
• Chat latency under 500ms (feels conversational)
• 1-to-many fan-out is the core scaling challenge, not database throughput
• Video transcoding is CPU-intensive and must happen in real time

Now the architecture practically designs itself. You need:

1. Video ingest service: accepts RTMP/WebRTC from streamers, pushes to transcoding
2. Transcoding pipeline: converts to multiple bitrates (HLS/DASH segments), async workers
3. CDN distribution: edge servers cache video segments, handles the 1-to-N fan-out
4. Chat service: WebSocket connections, pub-sub per stream channel (Redis Pub/Sub or similar)
5. Discovery service: stream metadata in a database, search index for browsing

You didn't need to have used Twitch. You needed to decompose what the system does and recognize: "the video part is a CDN pipeline, the chat part is a pub-sub system, and the discovery part is a search index." Each piece maps to patterns you already know.

---

Worked Example 2: Elevator System

Here's one that throws people because it doesn't feel like a "web system." The interviewer says: "Design an elevator control system for a 50-story building with 8 elevators."

Step 1: WHO uses it?

• Riders: press buttons on floors and inside elevators
• Building management: configure rules (express elevators, maintenance mode)
• Maintenance staff: take elevators offline, run diagnostics

Step 2: WHAT data flows?

• Elevator state (current floor, direction, door status, passenger count)
• Floor requests (external: "I'm on floor 12, going up"; internal: "take me to floor 30")
• Configuration rules (elevator 1-2 are express to floors 30-50)

Step 3: WHAT operations?

• Request pickup from a floor (write + event)
• Select destination floor inside elevator (write)
• Dispatch: decide which elevator serves which request (the core algorithm)
• Update elevator position in real time (streaming state)

Step 4: HOW MUCH scale? This is a bounded system. 8 elevators, 50 floors, maybe 2,000 people in the building. Scale isn't the challenge here. The challenge is the scheduling algorithm and real-time state management.

Step 5: WHAT constraints?

• Minimize average wait time across all riders
• Handle peak times (morning arrival, lunch, end of day)
• Safety: doors don't close on people, elevators don't move with open doors
• Real-time: decisions must be made within milliseconds

Now the pattern recognition kicks in. Each elevator is a state machine with states like IDLE, MOVING_UP, MOVING_DOWN, DOORS_OPEN, and MAINTENANCE. The dispatch problem is a scheduling algorithm (similar to task scheduling, process scheduling in an OS, or even ride-matching in Uber).

The core components:

1. Elevator State Manager: tracks the real-time state of each elevator (state machine per elevator)
2. Request Queue: incoming floor requests, prioritized by direction and proximity
3. Dispatch Scheduler: the algorithm that assigns requests to elevators (SCAN/LOOK algorithm, or nearest-car)
4. Sensor Interface: door sensors, weight sensors, floor position sensors feeding state updates
5. Configuration Service: express rules, maintenance mode, peak-hour policies

This is not a database-heavy distributed system. It's a real-time state machine with a scheduling optimizer. If you've studied task schedulers, OS process scheduling, or even ride-matching algorithms, you have the toolkit.

The algorithm choice is the interesting deep-dive: SCAN (elevator sweeps up then down, serving requests in order) vs. LOOK (like SCAN but reverses direction when no more requests ahead) vs. nearest-car (dispatches closest idle elevator). Each has trade-offs in wait time, throughput, and fairness.

---

The Recovery Script

If you feel the freeze coming, use this internal script to get unstuck in under 90 seconds:

1. "Who are the users?" Write down 2-3 user types on the whiteboard.
2. "What do they do?" List 3-5 core actions next to each user type.
3. "What data does that create?" Sketch 3-5 entities with arrows between them.
4. "What's the read path? What's the write path?" Trace one read and one write through your entities.
5. "What would break at scale?" Circle the bottleneck. This is your architectural focus.

Say step 1 out loud: "Let me start by identifying the user types and core actions." The interviewer now sees a structured thinker, not someone who's lost.

---

What You Already Know (and Don't Realize)

Almost every system design prompt, no matter how exotic, reduces to a combination of these building blocks:

When you hear "Design a smart home system," you're hearing: state machines (device states) + event pipeline (sensor data) + CRUD API (device management) + real-time messaging (push notifications to the app).

When you hear "Design an airport baggage tracking system," you're hearing: inventory tracking (bag = item with a lifecycle) + event pipeline (scan events at checkpoints) + state machine (bag states: checked-in, loaded, in-transit, arrived, claimed).

My recommendation: practice the analogy bridge on 5 weird prompts before your interview. Pick systems you've never thought about (parking, elevators, vending machines, traffic lights, library management) and decompose each into known building blocks. The pattern recognition becomes automatic.

---

Common Mistakes

Mistake 1: Memorizing solutions instead of learning to decompose. If you've memorized 20 system designs but can't decompose the 21st from scratch, you have the wrong skill. Interviewers increasingly choose unusual prompts to test exactly this.

Mistake 2: Panic-driven over-engineering. You don't know the system, so you throw every tool at it: sharding, Kafka, Redis, a service mesh, Kubernetes. The interviewer sees anxiety, not architecture. Start simple. A parking garage for one location doesn't need Kafka.

Mistake 3: Refusing to acknowledge the gap. Pretending you know a system you don't is worse than admitting it. "I haven't built a streaming platform, but the core challenge is 1-to-many video distribution with low latency" shows you can reason about systems you haven't memorized.

Mistake 4: Skipping the "what makes this different" question. Every system has one thing that makes it uniquely challenging. For Twitch, it's fan-out. For elevators, it's scheduling. For a parking garage, it's real-time capacity tracking. If you don't identify this, you'll design a generic CRUD app and miss the point entirely.

Mistake 5: Spending too long on decomposition without sketching. The decomposition should take 2-3 minutes, tops. If you're still listing entities at the 5-minute mark, start sketching with what you have. You can refine as you go.

---

How This Shows Up in Interviews

Interviewers use unfamiliar prompts deliberately. Here's what they're testing and how to pass.

When to use first-principles decomposition: every single time you hear a prompt you haven't practiced. Even for prompts you have practiced, starting with a quick decomposition shows structure.

Depth expected by level:

• Junior/Mid (E3-E4): Can identify users and core operations. Produces a working design even if it's not optimal. Asks clarifying questions about scale.
• Senior (E5): Maps the unknown system to known patterns fluently. Identifies the bottleneck unprompted. Communicates trade-offs specific to the system's constraints.
• Staff (E6+): Decomposes and architects simultaneously. Connects the system's constraints to specific technology choices with quantified reasoning. Drives the conversation proactively.

---

---

Quick Recap

1. Every unfamiliar system decomposes into five questions: WHO uses it, WHAT data flows, WHAT operations exist, HOW MUCH scale, and WHAT constraints are special. Write these on the whiteboard before sketching boxes.
2. The two failure modes (freezing and cargo-culting) both skip decomposition. Freezing shows no structure. Faking shows no understanding of what makes the problem unique.
3. Pattern matching is the core skill: map unknown systems to known building blocks (inventory, state machine, pub-sub, search index, event pipeline). Every exotic prompt reduces to 2-3 patterns you already know.
4. Name the hard problem explicitly after decomposing. "The core challenge here is X" signals that you understand what makes this system interesting, not just that you can draw boxes.
5. Acknowledge gaps honestly and immediately: "I haven't built this system, but the core challenge is low-latency fan-out" beats both silence and pretending. Interviewers test novelty-handling deliberately.
6. The decomposition should take 2-3 minutes maximum. If you're still listing entities at the 5-minute mark, start sketching with what you have and refine as you go.
7. Practice the analogy bridge on weird prompts before your interview: parking garages, elevators, vending machines, traffic lights. Five practice decompositions build the muscle memory that prevents panic.