How to handle unknown systems

Purpose

Use this article when a system-design prompt is unfamiliar or sits outside your usual domain. It gives you a calm way to turn an unknown domain into familiar sub-problems without pretending that the domain-specific details do not matter.

TL;DR

• Every unfamiliar system can be decomposed with five questions: Users, Data, Operations, Scale, and Constraints. Start there as a default.
• Two common failure modes are freezing (saying nothing) and faking (cargo-culting a memorized design). Both often skip the step that actually works.
• Pattern matching is the reusable skill: 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 five-question template (WHO, WHAT data, WHAT operations, HOW MUCH scale, WHAT constraints) is a robust starting point for unfamiliar prompts.

---

Mental Model

An unfamiliar domain becomes manageable when you translate its nouns and verbs into system concepts:

• Users and goals become actors, permissions, and use cases.
• Domain nouns become entities, state, relationships, and data stores.
• Domain verbs become reads, writes, commands, events, and workflows.
• Scale and timing reveal the capacity boundary: throughput, concurrency, storage, or geographic spread.
• Special constraints reveal the hard problem: safety, offline operation, fairness, privacy, freshness, or correctness.

Patterns are hypotheses, not templates. Map the unknown system to a known pattern, then validate the match against access patterns, scale, and constraints before committing to the architecture.

---

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.

A common mock-interview failure looks like this: the candidate knows distributed-systems concepts but has no method for applying them to something they have not rehearsed. The problem is not necessarily knowledge; it is the lack of a repeatable decomposition step.

An unfamiliar prompt is an opportunity to test transfer rather than recall. If you can only design systems you have memorized, the missing skill is the ability to derive a design from the domain's operations and constraints.

---

The Two Failure Modes

When you hit an unfamiliar prompt, candidates commonly 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..." This leaves little visible structure or 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. This can look like memorization without understanding.

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

If you feel the freeze coming on, say out loud "Let me take 60 seconds to decompose this before sketching." That creates a short planning window and makes the structure visible.

---

The First-Principles Decomposition Template

Many systems, no matter how exotic, can be explored with the same five questions. The WHO-WHAT-HOW framework is a useful starting point; adapt it when the domain has additional safety, regulatory, or physical constraints.

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).

A practical habit: write these five questions on the whiteboard before sketching boxes. Give yourself about 90 seconds, then start drawing with the information you have and refine it as you learn more.

---

The Analogy Bridge: Connecting Unknown to Known

Here's where preparation helps even for systems you've never seen. Many system design problems map 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.

Candidates who practice this analogy bridge can approach prompts like "Design a smart thermostat network" or "Design an airport baggage tracking system" without memorizing those exact systems. The useful move 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 major architecture choices become easier to justify. 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.

---

Adapting the Template

The five questions stay stable, but their emphasis changes with the domain:

• For a bounded physical system, prioritize safety invariants, state transitions, and local control before throughput.
• For a large online service, prioritize access patterns, hot paths, capacity, and failure isolation.
• For an offline or intermittently connected system, decide what must work locally and how conflicting updates reconcile later.
• For a regulated or life-safety system, clarify auditability, retention, human override, and the failure behavior that is safe by default.

If the analogy stops fitting, keep the useful pieces and replace the mismatched one. A reservation pattern may explain parking-space allocation, while local edge state and safety rules require a different control path.

---

The Recovery Script

If you feel the freeze coming, use this script to get unstuck in about 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." This makes your next moves visible instead of leaving the pause unexplained.

---

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).

A useful practice: try the analogy bridge on five unfamiliar prompts before the 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 faster and easier to retrieve.

---

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 practiced recall without transfer. An unfamiliar prompt tests whether you can derive the relevant patterns.

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. Most systems have at least one thing that makes them 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 it, you risk designing a generic CRUD app and missing the point.

Mistake 5: Spending too long on decomposition without sketching. Aim to finish the initial decomposition in 2-3 minutes. 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

When a prompt is unfamiliar, the evaluation often focuses on how you structure uncertainty. Here's what to make visible.

When to use first-principles decomposition: as the default when you hear a prompt you haven't practiced. Even for prompts you know, 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.

---

---

30-Second Explanation

“When I do not recognize a system, I do not start with a memorized architecture. I identify who uses it, what data flows, what operations matter, how much scale is required, and what constraints make the domain special. Then I map those pieces to known patterns, name the hardest problem, and validate the analogy before adding complexity.”

5-Minute Explanation

1. Acknowledge the unfamiliarity and announce the plan: “I’ll decompose this from first principles.”
2. List two or three user types and their core actions.
3. Name three to five entities, then trace one read, one write, and any important event.
4. Ask for scale and quantify the likely bottleneck: throughput, concurrency, storage, or geographic spread.
5. Identify the special constraint—such as safety, offline operation, fairness, freshness, or regulatory handling—and map the system to two or three known patterns.
6. State the first architecture and its adaptation: “This resembles inventory plus reservation, but the gate’s latency requirement means capacity lookup must stay local.”

The goal is a defensible first design in five minutes, not a complete domain specification.

---

Quick Recap

1. A useful default for an unfamiliar system is 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). Many exotic prompts can be explained with two or three patterns plus domain-specific constraints.
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" is better than both silence and pretending. An interview may test how you handle novelty.
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.

Related Concepts

• Scoping the problem — turn an open-ended prompt into a tractable scope before decomposing it.
• Approach and structure — organize requirements, estimates, flows, and trade-offs into a coherent answer.
• Common pitfalls — recognize over-engineering, hidden assumptions, and missed failure modes.
• Stateful vs. stateless design — useful context for deciding where lifecycle state should live in a device or workflow system.

---