Arquitetura

Um agent sozinho é como aquele microserviço que nasceu pequeno e, de repente, quer resolver tudo. Funciona até certo ponto. Depois vira confusão. Quando a tarefa cresce, especialização ajuda. Se você já migrou de monolito pra microservices, o raciocínio aqui vai soar familiar. As perguntas são quase as mesmas. Como eles se comunicam? Quem coordena? O que acontece quando um falha? Quanto custa essa coordenação? O mapa pro profissional de infra Conceito Multi-Agent O que faz Equivalente em infra Orchestrator Coordena agents, delega tarefas API Gateway, Workflow engine Worker agent Executa tarefas específicas Microserviço Message passing Comunicação entre agents Message queue (Service Bus) Shared state Dados compartilhados entre agents Database, Redis Handoff Transferir contexto entre agents Request forwarding Supervisor Monitora e intervém quando algo falha Kubernetes controller, watchdog Consensus Múltiplos agents concordam numa decisão Raft, quorum Quando usar multi-agent Cenário Single agent Multi-agent Task de 3-5 steps num domínio Ideal Overkill Task que cruza múltiplos domínios (DB + rede + app) Fica confuso Ideal Task onde diferentes partes precisam de tools diferentes Tools demais Separação natural Task onde precisas de “second opinion” Possível (reflection) Mais robusto Task com trabalho paralelizável Limitado Escala melhor Regra prática: se um agent já está carregando tools demais e você precisa explicar o mapa inteiro do mundo pra ele funcionar, provavelmente chegou a hora de quebrar em mais de um. ...

Se agents são controllers (LLM + tools + loop), padrões agentic são os design patterns que esses controllers usam. Assim como em software tradicional você tem Observer, Strategy e Chain of Responsibility, em AI agents também existem padrões que aparecem o tempo todo. Saber reconhecer esses patterns encurta bastante o caminho. Em vez de desenhar tudo do zero a cada caso, você monta a solução com blocos que já provaram valor. ...

No post anterior, eu destrinchei como agents funcionam: LLM, tools e loop. Agora a conversa muda de nível. O problema não é fazer um demo de 5 minutos. É projetar um agent que aguente produção, rode 24/7 e não precise de babá. Continua sendo design de sistema, com as perguntas de sempre: quais são os requisitos, quais os failure modes, como escala e como monitora? As 5 decisões de design Projetar um agent normalmente vira 5 decisões: ...

O time de ML treinou um modelo que funciona no notebook. Accuracy de 94%. Todo mundo comemora. Aí vem a parte menos glamourosa: colocar isso em produção. “Dá pra colocar isso numa API com 99.9% de uptime, latência < 200ms e 10K requests por segundo?” É aqui que system design de ML cai no colo de infra. A boa notícia é que a maior parte do problema parece familiar. Serving, rollout, observabilidade e capacity planning continuam sendo trabalho de sistema distribuído. O pedaço realmente diferente existe, mas é menor do que o hype sugere. ...

“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: ...

“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. No papel parece simples: “me mostra os posts de quem eu sigo em ordem cronológica”. Em produção vira outro bicho 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. ...

“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. O que impressiona aqui não é só a escala, mas a pressão simultânea por latência baixa, conexões persistentes e durabilidade. ...

“Design a video-sharing platform like YouTube.” Essa é uma das perguntas mais clássicas de system design porque um sistema de vídeo encosta em quase tudo que costuma cair na entrevista: upload grande, processamento assíncrono, storage massivo, CDN global, adaptive streaming e leitura pesada com cache. 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. ...

Você está numa entrevista. O entrevistador vira e fala: “Design a video-sharing platform like YouTube.” Você tem 45 minutos. O que faz primeiro? Se a resposta for “começo desenhando caixinhas no diagrama”, você já perdeu. System design não é sobre saber a resposta certa. É sobre mostrar como você pensa quando o problema ainda está meio em aberto. E isso melhora com framework, prática e repertório. Este é o primeiro artigo da série System Design na Prática. Nos próximos posts eu vou aplicar esse framework em sistemas reais como YouTube, WhatsApp, Uber e Twitter. Mas antes precisamos do toolkit mental. Esse artigo é o seu canivete suíço. ...