Aula

System design C1: design and trade-offs

Nível: C1

Objetivo

Conduzir a fase de desenho em uma system design interview em C1, com high-level architecture, data flow, storage, APIs, queues, caching, consistency e reliability, explicando cada escolha e a alternativa rejeitada. O foco é mostrar que cada componente tem trade-off, e que a recomendação é uma escolha consciente.

Explicação

A fase de desenho em system design C1 segue a fase de requisitos. Quatro blocos:

1. High-level architecture

O engenheiro C1 começa com um diagrama de caixas em alto nível: cliente, API gateway, serviços, banco, cache, filas. O diagrama é uma planta, não um detalhe: o suficiente para a audiência entender o fluxo e perguntar. Em entrevista, começar por um diagrama detalhado antes do alto nível é o erro que mata a sessão.

2. Data flow

O data flow mostra como um request atravessa o sistema: o cliente faz POST, o gateway valida, o serviço grava no banco, o cache é invalidado, a fila dispara o evento. C1 descreve o fluxo em uma frase por etapa, com verbo no presente. `The request hits the gateway, is validated, written to the primary database, the cache is invalidated, and a click event is published to the queue.` Sem fluxo, o diagrama é estático.

3. Componentes: storage, APIs, queues, caching, consistency, reliability

Cada componente tem trade-off. C1 não diz 'usamos Redis' — diz 'usamos Redis como cache de leitura com TTL de 5 minutos, e invalidamos explicitamente em escrita; a alternativa era cache apenas com TTL, mas isso pode servir dados stale por até 5 minutos'. Para cada escolha, o engenheiro C1 nomeia o que escolheu, por que escolheu, e o que rejeitou.

Storage: SQL para dados relacionais com transações; NoSQL para dados sem schema fixo; blob storage para arquivos. Trade-off: consistência vs flexibilidade.
APIs: REST para simplicidade; gRPC para performance; GraphQL para flexibilidade. Trade-off: simplicidade vs performance vs flexibilidade.
Queues: para desacoplar produtores e consumidores; at-least-once vs at-most-once vs exactly-once. Trade-off: latência vs garantia.
Caching: read-through, write-through, cache-aside. Trade-off: simplicidade vs invalidação.
Consistency: strong vs eventual. Trade-off: correção vs latência.
Reliability: replicação, failover, backup. Trade-off: custo vs disponibilidade.

4. Trade-offs explícitos

A última parte da fase de desenho é a tabela de trade-offs ou a frase que sintetiza as escolhas. `We chose Option A for the cache, with the trade-off that we may serve stale data for up to 5 minutes; we accepted this because the alternative (synchronous invalidation) would add 30 ms to every write.` Em entrevista, fechar com trade-off explícito é o que separa sênior de pleno.

Exemplos

Inglês	Tradução	Observação
The request hits the gateway, is validated, written to the primary database, the cache is invalidated, and a click event is published to the queue.	A requisição chega no gateway, é validada, gravada no banco primário, o cache é invalidado, e um evento de clique é publicado na fila.	Data flow em uma frase por etapa, com verbo no presente.
We use Redis as a read cache with a 5-minute TTL, and we invalidate explicitly on write; the alternative was TTL-only cache, which may serve stale data for up to 5 minutes.	Usamos Redis como cache de leitura com TTL de 5 minutos, e invalidamos explicitamente na escrita; a alternativa era cache apenas com TTL, que pode servir dados stale por até 5 minutos.	Escolha + alternativa rejeitada + trade-off explícito.
We chose SQL for the user data because we need transactions; we chose NoSQL for the click events because the schema is flexible and we need write throughput.	Escolhemos SQL para os dados de usuário porque precisamos de transações; escolhemos NoSQL para os eventos de clique porque o schema é flexível e precisamos de throughput de escrita.	Storage trade-off com razão por componente.
We chose cache-aside over write-through because the write path is on the critical latency budget; the trade-off is that the application must handle cache misses explicitly.	Escolhemos cache-aside em vez de write-through porque o caminho de escrita está no orçamento crítico de latência; o trade-off é que a aplicação precisa lidar com cache miss explicitamente.	Trade-off explícito: escolha + razão + consequência.

Erros comuns

Desenhar detalhe antes do alto nível: o entrevistador se perde antes de entender o fluxo.
Listar tecnologia sem trade-off: 'usamos Redis' não é design; 'usamos Redis com TTL de 5 min, alternativa rejeitada foi X' é design.
Data flow estático: diagrama sem verbo no presente não mostra como o request atravessa o sistema.
Misturar armazenamento: tentar usar SQL para tudo é anti-pattern; C1 separa por tipo de dado e requirement.
Esconder o trade-off: 'escolhemos A' sem dizer o que foi rejeitado é propaganda, não design.

Prática guiada

Reescreva cada bloco abaixo no padrão C1 de system design: desenho e trade-offs.

High-level: troque 'usamos microserviços' por um diagrama de caixas em alto nível: cliente, gateway, serviço, banco, cache, fila.
Data flow: troque 'o usuário faz upload' por uma frase com verbo no presente para cada etapa.
Trade-off explícito: para cada escolha, nomeie o que escolheu, por que escolheu, e o que rejeitou.
Tabela de trade-offs: feche o design com uma frase que sintetize as escolhas e o que foi aceito como custo.

Compare a versão C1 com a versão genérica: a versão C1 mostra que cada escolha é consciente, não default.

Resumo

System design C1 — desenho começa com high-level architecture (caixas em alto nível), segue com data flow (verbo no presente, uma frase por etapa), depois componentes (storage, APIs, queues, caching, consistency, reliability) com trade-off explícito para cada escolha, e fecha com a síntese das escolhas e custos aceitos. Sem trade-off explícito, o design é propaganda; com trade-off, é engenharia.

Vocabulário

Palavras principais

10 itens

high-level architecturearquitetura de alto nível — caixas, não detalhes

Start with the high-level architecture, then drill down.

Comece com a arquitetura de alto nível, depois aprofunde.

data flowfluxo de dados — como o request atravessa o sistema

'The data flow is: request hits gateway, validated, written to DB, cache invalidated, event published.'

'O fluxo é: requisição chega no gateway, é validada, gravada no banco, cache invalidado, evento publicado.'

cache-asidecache-aside — aplicação lê do cache, em caso de miss lê do banco e popula o cache

We chose cache-aside for the read path.

Escolhemos cache-aside para o caminho de leitura.

write-throughwrite-through — escrita vai para o cache e o banco ao mesmo tempo

Write-through adds latency to the write path.

Write-through adiciona latência ao caminho de escrita.

TTL (time to live)TTL — tempo de vida do item no cache

We use a 5-minute TTL on the cache.

Usamos um TTL de 5 minutos no cache.

eventual consistencyconsistência eventual — todos os nós convergem, mas com atraso

We chose eventual consistency for the click events.

Escolhemos consistência eventual para os eventos de clique.

strong consistencyconsistência forte — todos os nós veem o mesmo valor em qualquer momento

Strong consistency is required for the payment data.

Consistência forte é necessária para os dados de pagamento.

at-least-once deliveryentrega pelo menos uma vez — pode duplicar, mas não perde

We chose at-least-once delivery for the click events; the consumer must be idempotent.

Escolhemos entrega pelo menos uma vez para os eventos de clique; o consumidor precisa ser idempotente.

replicationreplicação — cópia dos dados em múltiplos nós

We use synchronous replication for the primary database.

Usamos replicação síncrona para o banco primário.

failoverfailover — chaveamento automático para um nó reserva em caso de falha

Failover is automatic in this design.

O failover é automático neste design.

História

História: System design C1: design and trade-offs

Nível: C1

História em inglês

Designing a URL shortener in the interview

After the requirements phase, I moved to the design phase of the URL shortener. I started with the high-level architecture: client, API gateway, shorten service, redirect service, primary database, read cache, and a queue for analytics events. I described the data flow: the client POSTs a long URL to the gateway; the gateway validates and forwards to the shorten service; the service writes to the primary database, returns the short code, and publishes a click event to the queue. I named the trade-offs: SQL for the URL mapping because we need transactions; Redis cache-aside for reads with a 5-minute TTL and explicit invalidation; at-least-once delivery on the queue because the consumer is idempotent. I closed the design with: we accepted eventual consistency on the click events and 5 minutes of staleness on the read cache in exchange for p99 under 50 ms and 99.9% availability. The interviewer said: the design was clean, the trade-offs were explicit, and I would hire this candidate.

Tradução linha por linha

Inglês	Tradução
After the requirements phase, I moved to the design phase of the URL shortener.	Depois da fase de requisitos, eu passei para a fase de design do encurtador de URL.
I started with the high-level architecture: client, API gateway, shorten service, redirect service, primary database, read cache, and a queue for analytics events.	Eu comecei com a arquitetura de alto nível: cliente, API gateway, serviço de encurtamento, serviço de redirecionamento, banco primário, cache de leitura, e uma fila para eventos de analytics.
I described the data flow: the client POSTs a long URL to the gateway; the gateway validates and forwards to the shorten service; the service writes to the primary database, returns the short code, and publishes a click event to the queue.	Eu descrevi o fluxo de dados: o cliente faz POST com a URL longa no gateway; o gateway valida e encaminha para o serviço de encurtamento; o serviço grava no banco primário, retorna o código curto, e publica um evento de clique na fila.
I named the trade-offs: SQL for the URL mapping because we need transactions; Redis cache-aside for reads with a 5-minute TTL and explicit invalidation; at-least-once delivery on the queue because the consumer is idempotent.	Eu nomeei os trade-offs: SQL para o mapeamento de URL porque precisamos de transações; Redis cache-aside para leituras com TTL de 5 minutos e invalidação explícita; entrega pelo menos uma vez na fila porque o consumidor é idempotente.
I closed the design with: we accepted eventual consistency on the click events and 5 minutes of staleness on the read cache in exchange for p99 under 50 ms and 99.9% availability.	Eu fechei o design com: aceitamos consistência eventual nos eventos de clique e 5 minutos de staleness no cache de leitura em troca de p99 abaixo de 50 ms e 99,9% de disponibilidade.
The interviewer said: the design was clean, the trade-offs were explicit, and I would hire this candidate.	O entrevistador disse: o design foi limpo, os trade-offs foram explícitos, e eu contrataria este candidato.

Notas de vocabulário

high-level architecture: client, gateway, service, DB, cache, queue = planta em alto nível antes de qualquer detalhe.
the service writes to the primary database, returns the short code, and publishes an event = data flow com verbo no presente.
SQL because we need transactions = escolha com razão (não 'usamos SQL').
cache-aside for reads with TTL and explicit invalidation = trade-off explícito: escolha + invalidação.
at-least-once delivery because the consumer is idempotent = garantia de entrega + razão da escolha.
we accepted ... in exchange for ... = frase C1 de trade-off final: o que foi aceito como custo.

Perguntas de compreensão

Por que começar com high-level em C1?
O que torna um data flow C1 útil?
O que diferencia uma escolha C1 de propaganda?
O que é a frase final de trade-off em C1?

Prática com a história

Escreva um data flow C1 em uma frase por etapa para um sistema de upload de imagem.
Nomeie uma escolha de cache C1 com trade-off explícito.
Feche o design com a frase 'we accepted X in exchange for Y'.

Prática

Exercícios e teste

Próxima etapa

4blocos de exercícios disponíveis neste tema

11questões de teste para revisar depois da aula

A próxima melhoria é transformar esses arquivos em perguntas com resposta no navegador. Por enquanto, esta página já organiza o estudo e permite seguir a aula inteira sem abrir os arquivos manualmente.