System Design e a habilidade de projetar a arquitetura de sistemas de software que atendam milhoes de usuarios de forma confiavel e escalavel. E uma das competencias mais valorizadas em entrevistas de empresas de tecnologia e no dia a dia de desenvolvedores senior. Este guia ensina os fundamentos que todo dev precisa dominar.
Por que System Design importa
Quando um sistema tem 100 usuarios, quase qualquer arquitetura funciona. Quando tem 100 mil usuarios, decisoes erradas comecem a doer. Com 10 milhoes de usuarios, a arquitetura e a diferenca entre o sistema funcionar ou cair.
System design e sobre tomar decisoes informadas: qual banco de dados usar, como escalar horizontalmente, onde colocar caches, como garantir disponibilidade. Nao existe resposta unica — cada decisao envolve tradeoffs.
Os pilares do System Design
Escalabilidade
Escalar verticalmente (vertical scaling): aumentar os recursos de um unico servidor (mais RAM, CPU, disco). Simples, mas tem limite fisico e custo exponencial.
Escalar horizontalmente (horizontal scaling): adicionar mais servidores para distribuir a carga. Mais complexo (exige stateless services, load balancing, dados distribuidos), mas escalabilidade teoricamente ilimitada.
Disponibilidade e confiabilidade
Disponibilidade se mede em “noves”: 99% = 3.65 dias de downtime/ano, 99.9% = 8.76 horas/ano, 99.99% = 52.6 minutos/ano, 99.999% = 5.26 minutos/ano.
Para alta disponibilidade: redundancia em tudo (servidores, bancos, rede), failover automatico (se um no cai, outro assume), health checks e auto-healing.
Latencia e throughput
Latencia: tempo para processar uma unica requisicao (em milissegundos). Throughput: numero de requisicoes que o sistema processa por segundo (RPS).
Numeros que todo dev deve ter na cabeca: acesso a cache L1: 0.5ns. RAM: 100ns. SSD: 150us. Rede dentro do datacenter: 500us. HDD: 10ms. Rede entre continentes: 150ms.
Componentes de sistema: o toolkit
Load Balancer
Distribui trafego entre multiplos servidores. Algoritmos: Round Robin (distribui sequencialmente), Least Connections (servidor com menos conexoes ativas), IP Hash (mesmo IP sempre vai pro mesmo servidor — util para sessoes). AWS ALB, Nginx, HAProxy sao opcoes comuns.
Cache
Armazena resultados de operacoes caras para reutilizacao rapida. Redis e Memcached sao os mais usados. Estrategias de cache: Cache-aside (aplicacao consulta cache primeiro, se nao tem, busca no banco e popula o cache), Write-through (escreve no cache e no banco simultaneamente), Write-behind (escreve no cache e asincronamente no banco).
Cache invalidation e o problema mais dificil: quando o dado muda no banco, como atualizar o cache? TTL (time to live), event-driven invalidation e versionamento sao as abordagens comuns.
CDN (Content Delivery Network)
Servidores distribuidos geograficamente que armazenam conteudo estatico (imagens, CSS, JS, videos) proximo ao usuario. CloudFront, Cloudflare, Akamai. Reduz latencia e carga nos servidores de origem.
Message Queue
Desacopla componentes permitindo comunicacao assincrona. Producer envia mensagem na fila, consumer processa quando estiver pronto. RabbitMQ, Amazon SQS, Apache Kafka. Fundamental para processamento em background, integracao entre microservicos e nivelamento de carga.
Exemplo pratico: design de um URL Shortener
Requisitos: encurtar URLs longas em URLs curtas (7 caracteres), redirecionar URLs curtas para as originais, suportar 100 milhoes de URLs, 10 mil encurtamentos/dia, 100 mil redirecionamentos/segundo.
Estimativas: 100M URLs x 500 bytes = 50GB de storage. 100K RPS de leitura (pesado em leitura = bom candidato para cache).
Componentes: API (gera hash de 7 chars para a URL, armazena no banco, retorna URL curta), banco de dados (armazena mapeamento hash -> URL original — NoSQL como DynamoDB e ideal pela simplicidade do modelo), cache Redis (armazena URLs mais acessadas — 20% das URLs geram 80% do trafego), CDN para redirecionar as URLs mais populares sem chegar no servidor.
Geracao do hash: Base62 encoding de um contador auto-incrementante (a-z, A-Z, 0-9 = 62 caracteres, 7 posicoes = 3.5 trilhoes de combinacoes).
Como estudar System Design
O livro “Designing Data-Intensive Applications” (DDIA) de Martin Kleppmann e a referencia principal. System Design Interview (Alex Xu) para preparacao especifica para entrevistas. Canais no YouTube: ByteByteGo, Gaurav Sen, Hussein Nasser. Na pratica: leia post-mortems de incidentes de empresas reais (Netflix Tech Blog, Uber Engineering, Nubank Blog) para entender decisoes arquiteturais e falhas.
Tem um projeto em mente?
Somos especialistas em transformar ideias em produtos digitais. Apps, sites, automações e IA — vamos construir juntos.