Um desenho começa pela pergunta
System Design não é preencher uma tela com serviços conhecidos. Comece pelo que o sistema precisa fazer e pelas condições que importam. Para uma plataforma de cursos: listar cursos, abrir aulas, acompanhar progresso. Depois registre restrições como disponibilidade, privacidade, latência aceitável, equipe e custo operacional.
Defina limites e responsabilidades com diagramas de contexto e containers do C4, ou com qualquer desenho que o time consiga ler. Uma caixa deve representar algo identificável e uma linha deve dizer se transporta chamada, evento ou dado. A granularidade depende da decisão que queremos discutir.
Não confunda requisito com solução
“Precisa escalar” ainda é vago. Pergunte qual operação, qual volume, qual crescimento e que demora é aceitável. Só então discuta cache, filas, réplicas ou particionamento. Uma solução sem cenário mensurável é difícil de avaliar.
Recupere: que perguntas transformariam “o sistema precisa ser rápido” num requisito verificável?
Material complementar da Fernanda
- Guia de System Design — Comece pelos requisitos funcionais e não funcionais e avance para o caso NotiFly. Defina carga, latência e falhas toleráveis antes de escolher componentes. Em CAP, o conflito é entre consistência e disponibilidade durante uma partição de rede; escalabilidade não é o P.
Pratique com /aprender
/aprender Modele em alto nível uma plataforma que publica cursos e registra progresso. Peça que eu liste atores, operações e requisitos de qualidade antes de desenhar componentes. Questione números vagos como “muito tráfego” e me ajude a formular uma restrição verificável.