What clarifying questions should I ask during a system design interview?

Ask clarifying questions that change the design: who uses the system, which features are in scope, what scale to support, what latency and availability matter, how consistent the data must be, and what can be excluded. Good clarifying questions make you sound prepared because they explain the trade-off you are about to make.

The goal is not to ask many questions. The goal is to remove the ambiguity that would cause the wrong architecture.

Use these categories at the start of the interview.

Product scope

• Who are the users?
• What are the top two or three user actions?
• What is explicitly out of scope?

Scale

• How many daily active users?
• What is the expected read/write ratio?
• Are there peak events or viral traffic?

Latency

• Which path must be fast?
• Is this request/response, streaming, or async?
• Is p99 latency important?

Availability and durability

• Can the system be temporarily unavailable?
• Can data ever be lost?
• Is recovery time more important than strict consistency?

Consistency

• Does a user need to read their own writes immediately?
• Can different users see stale data?
• Does money, inventory, or ranking correctness matter?

Geography and compliance

• Is this global or single-region?
• Are there data residency constraints?
• Are there privacy or audit requirements?

These questions map directly to System Design Structure and Consistency Patterns.

For Design WhatsApp, weak questions sound like:

• "Should it scale?"
• "Should I use WebSockets?"

Better questions:

• "Are we designing one-on-one messaging only, or group chat too?"
• "Do messages need to be delivered when the recipient is offline?"
• "Should online presence be exact or eventually consistent?"
• "Do we need read receipts and typing indicators?"
• "Is message history stored forever?"

Those answers change the design. Offline delivery points toward durable message storage and queues. Presence points toward ephemeral state, which is covered in Presence and Ephemeral State. Read receipts create additional write paths. Group chat introduces fan-out strategies.

Asking questions with no design impact. If the answer will not change the design, skip it.

Asking the interviewer to design for you. "What database should I use?" is not a clarifying question. "Do we need strong consistency for this write?" is.

Waiting too long. Clarify the important constraints before the architecture. You can ask follow-up questions later, but the first five minutes should narrow the problem.

Ignoring the answer. If the interviewer says analytics can be delayed, do not put analytics on the critical path. Use async processing, queues, or batch jobs. See Message Queues and Asynchronous Processing & DAGs.

Open /practice and force yourself to write clarifying questions before any design. Good prompts:

• Rate Limiter: ask about global vs per-region limits, fail-open behavior, and exactness
• Dropbox: ask about file size, sync conflicts, sharing, and offline devices
• Internal Ledger: ask about auditability, idempotency, and reconciliation

Then connect each answer to a requirement and each requirement to a component.

Clarifying questions are not a formality. They are the first design step. Ask questions that expose constraints, then let those constraints drive the architecture.