Posts

Décimo terceiro post da série. No anterior, diagnosticamos os incidentes que acordam a gente de madrugada. Agora algo diferente: como usar AI pra melhorar o trabalho de infraestrutura em si. Inversão de perspectiva Nos últimos 12 posts, você construiu infra pra AI: GPUs, clusters, pipelines, segurança, monitoramento, cost management. Você virou expert em prover compute pra data scientists. Mas e usar AI pro seu trabalho? Análise de logs, detecção de anomalias, capacity planning, geração de IaC, incident response automatizado. AIOps não é buzzword novo; é a aplicação prática do que você já entende (modelos, inference, tokens) no seu dia a dia operacional. ...

Décimo segundo post da série. No anterior, operamos Azure OpenAI com HA e retry correto. Agora: quando as coisas quebram (e vão quebrar). Este post é organizado como cenários reais de falha. Cada um segue: Sintomas → Diagnóstico → Root Cause → Resolução → Prevenção. Leia uma vez pra reconhecimento de padrões. Depois deixe bookmarkado; você vai voltar aqui. Cenário 1: NVIDIA driver crash após kernel update Sintomas Segunda de manhã. Time de ML reporta que todos os workloads GPU falharam no fim de semana. Ninguém deployou nada. Você faz SSH: ...

Décimo primeiro post da série. No anterior, construímos a plataforma AI self-service com multi-tenancy e scheduling. Agora: o serviço que todo mundo quer consumir, Azure OpenAI, e como operá-lo sem tomar 429 na cara. O 429 que mudou tudo Seu time lançou um chatbot GPT-4o interno na segunda-feira. Dia 1: smooth sailing, demos pra liderança, Slack cheio de elogios. Dia 3: “o bot tá lento”. Dia 5: 30% dos requests retornam HTTP 429. Você abre Azure Monitor e descobre que está batendo no teto de 80K TPM. ...

“Design a URL shortening service like Bitly or TinyURL.” Essa é geralmente a primeira pergunta de system design que candidatos encontram. Parece simples: recebe URL longa, retorna URL curta, redireciona quando acessam. Dá pra fazer em 50 linhas de código, certo? Certo. Pra 100 usuários. Agora faz isso pra 100 bilhões de URLs com 100.000 redirects por segundo e vamos ver o quão “simples” é. O URL Shortener é o exercício perfeito pra fechar a série porque combina decisões aparentemente simples que revelam profundidade quando você puxa o fio: ...

Décimo post da série. No anterior, controlamos custos com Spot VMs, right-sizing e FinOps. Agora: como parar de ser um help desk humano pra GPU. O canal do Slack que comeu sua agenda Seis meses atrás, você provisionou um único VM GPU pro time de ML. Configurou drivers, montou storage, fechou o ticket. Pareceu qualquer outro request de infraestrutura. Hoje, você tem quatro times, três clusters AKS, dezenas de GPU node pools e uma coleção crescente de endpoints Azure OpenAI. Cada time quer seus recursos, suas quotas e seus SLAs. Seus DMs viraram help desk: “Dá pra dar mais GPUs?” “Por que meu training job está Pending?” “Quem tá usando todas as A100s?” ...

“Design a social media feed like Twitter.” Se YouTube é sobre arquivos grandes, WhatsApp sobre entrega garantida, e Uber sobre dados em movimento, Twitter é sobre o problema mais traiçoeiro de todos: fan-out. Um único tweet de alguém com 50 milhões de followers precisa aparecer na timeline de cada um deles, em segundos. O que parece simples (“mostrar posts de quem eu sigo em ordem cronológica”) se torna um monstro de engenharia quando a escala é: ...

“Design a ride-sharing platform like Uber.” Se YouTube é sobre throughput de dados e WhatsApp sobre latência de mensagens, Uber é sobre dados em movimento. Literalmente. Milhões de carros se movendo simultaneamente, e o sistema precisa saber onde cada um está, a cada segundo, pra conectar passageiros e motoristas em tempo real. O desafio do Uber é único porque combina: Geolocalização em tempo real (milhões de pontos se movendo) Matching otimizado (encontrar o melhor motorista, não apenas o mais próximo) Cálculo de rota e ETA (com condições de tráfego variando) Pricing dinâmico (oferta e demanda flutuando por região e minuto) Tudo isso com latência perceptível pro usuário de < 3 segundos entre apertar “pedir corrida” e ver o motorista atribuído. ...

Nono post da série. No anterior, blindamos a plataforma contra prompt injection e data leakage. Agora: como não falir no processo. A segunda-feira de R$650.000 Segunda de manhã. Café na mão, e-mail do financeiro no subject line: “URGENTE: fatura Azure $127.000, explicar.” Forecast era $42.000. Dois VMs ND96isr_H100_v5, provisionados três semanas atrás pra um “experimento rápido”, nunca desligados. A ~$98/hora cada, rodando 24/7 por três semanas: $33.000 em GPU parada. Ninguém usando. Ninguém lembrava que existiam. ...

“Design a messaging system like WhatsApp.” Se o YouTube é o exercício clássico de throughput e storage, WhatsApp é o exercício clássico de latência e conexões persistentes. O desafio muda completamente: em vez de entregar arquivos grandes pra milhões de viewers passivos, precisamos entregar mensagens pequenas pra bilhões de usuários em tempo real e garantir que nenhuma se perca. WhatsApp processa mais de 100 bilhões de mensagens por dia com uma equipe historicamente pequena (~50 engenheiros quando foi adquirido pelo Facebook em 2014). Esse é o poder de boas decisões arquiteturais. ...

“Design a video-sharing platform like YouTube.” Essa é possivelmente a pergunta de system design mais clássica que existe. E o motivo é simples: um sistema de vídeo toca em quase todo conceito importante: upload de arquivos grandes, processamento assíncrono, storage massivo, CDN global, adaptive streaming, e leitura pesada com caching agressivo. Nesse artigo, vamos aplicar o framework do post anterior pra projetar uma plataforma de vídeo do zero. Não vou fingir que estamos inventando o YouTube. Vou explicar por que cada decisão arquitetural faz sentido no contexto de escala real. ...