System design C1: requirements and scope

Nível: C1

Objetivo

Conduzir a fase de requisitos e escopo em uma system design interview ou RFC técnico em C1, com clarifying questions, functional and non-functional requirements, constraints, assumptions e success metrics bem delimitados. O foco é mostrar maturidade na abertura do problema antes de qualquer desenho.

Explicação

System design em C1 começa muito antes do desenho. A primeira metade é a fase de requisitos e escopo; sem ela, o desenho fica sem ancoragem e a audiência sênior percebe em 30 segundos.

1. Clarifying questions

A primeira coisa que o engenheiro C1 faz é perguntar, não desenhar. As perguntas certas cobrem cinco áreas:

• Funcionalidade: 'What are the core features? What is in scope and what is out?'
• Escala: 'How many users? How many requests per second at peak? How much data?'
• Latência e disponibilidade: 'What latency are we targeting? Is this latency-critical or throughput-critical?'
• Consistência: 'Do we need strong consistency, or is eventual acceptable?'
• Constraints: 'Are there compliance requirements? On-prem vs cloud? Existing systems we must integrate with?'

Sem clarifying questions, o candidato desenha um sistema genérico que não cabe no problema. Em entrevista, sem perguntas, o entrevistador assume que o candidato não vai escalar para sênior.

2. Functional vs non-functional requirements

Os functional requirements dizem o que o sistema faz: 'users can upload images, get a thumbnail, and share via link.' Os non-functional requirements dizem quão bem: 'p99 latency under 200 ms; 99.9% availability; support 10k concurrent uploads.' C1 separa os dois explicitamente; misturá-los é erro clássico.

3. Constraints e assumptions

Constraints são limites que não podem ser mudados: 'must run on AWS; budget capped at $20k/month; team has 4 engineers.' Assumptions são premissas que podem ser validadas: 'we assume 80% of uploads are under 5 MB.' Em C1, constraints e assumptions são listados separadamente; o entrevistador percebe maturidade quando vê a separação.

4. Success metrics

A frase final da fase de requisitos é a métrica de sucesso. 'The system is successful if: p99 latency is under 200 ms; 99.9% availability; cost per upload is under $0.001.' Success metrics em C1 são mensuráveis, numeradas e alinhadas ao negócio. Sem métricas, o sistema não tem como ser avaliado.

Exemplos

Erros comuns

• Pular clarifying questions: o desenho fica sem ancoragem; o entrevistador percebe em 30 segundos.
• Misturar functional com non-functional: 'users can upload quickly' mistura o que o sistema faz com quão bem.
• Tratar assumptions como constraints: assumption pode ser validada; constraint não. Misturar os dois esconde o que é fixo.
• Success metrics vagas: 'system should be fast and reliable' não é métrica; p99 < 200 ms é métrica.
• Esquecer de listar o que está fora de escopo: 'out of scope' delimita a conversa e impede feature creep.

Prática guiada

Reescreva cada bloco abaixo no padrão C1 de system design: requisitos e escopo.

1. Clarifying questions: troque 'the system should be fast' por perguntas sobre latência-alvo, pico de QPS, e dados.
2. Functional vs non-functional: separe o que o sistema faz (funcional) de quão bem (não-funcional).
3. Constraints vs assumptions: liste os dois separadamente; constraints não mudam, assumptions podem ser validadas.
4. Success metrics: troque 'system should be reliable' por 'p99 < 200 ms, 99.9% availability, cost per upload < $0.001'.

Compare a versão C1 com a versão genérica: a versão C1 delimita o problema antes de desenhar.

Resumo

System design C1 começa com clarifying questions sobre funcionalidade, escala, latência, consistência e constraints. Em seguida vem functional vs non-functional requirements (separados), constraints vs assumptions (listados separadamente), e success metrics mensuráveis e numeradas. Sem essa fase, o desenho fica sem ancoragem e o entrevistador percebe a falta de maturidade em 30 segundos.

História: System design C1: requirements and scope

Nível: C1

História em inglês

Opening a system design interview with clarifying questions

On Tuesday, I had a system design interview for a senior role. The interviewer asked me to design a URL shortener; I started with clarifying questions before any drawing. I asked: what is the peak QPS? Do we need analytics on the clicks? What is the latency target? Are there compliance requirements? I listed functional and non-functional requirements separately: functional, shorten URL, redirect, optional analytics; non-functional, p99 under 50 ms, 99.9% availability, support 10k QPS. I listed constraints and assumptions: constraints, must run on AWS, 4 engineers, budget $5k/month; assumptions, 80% of traffic is read, average URL lifetime 30 days. I closed the requirements phase with success metrics: p99 under 50 ms, 99.9% availability, cost per redirect under $0.0001. The interviewer said: that was the cleanest opening to a system design I have seen in a while.

Tradução linha por linha

Notas de vocabulário

• URL shortener = problema clássico de system design para sênior.
• peak QPS = pico de queries per second — pergunta obrigatória C1.
• analytics on the clicks = funcionalidade opcional, mas que muda o design (escrita adicional).
• 80% of traffic is read = assumption que direciona o design (cache primeiro).
• cost per redirect under $0.0001 = success metric alinhada ao custo, não só à latência.
• the cleanest opening = sinal de maturidade C1: a fase de requisitos vem antes do desenho.

Perguntas de compreensão

1. Por que começar com clarifying questions em C1?
2. O que diferencia functional de non-functional?
3. Por que separar constraints de assumptions?
4. O que torna uma success metric C1 útil?

Prática com a história

1. Escreva três clarifying questions C1 para um sistema de upload de imagens.
2. Escreva success metrics C1 mensuráveis para o mesmo sistema.
3. Separe 'must run on AWS' (constraint) de '80% of uploads are under 5 MB' (assumption).