weekly prompts 03 | a arquitetura que um estagiário entenderia
em ciência da computação só tem duas coisas difíceis...
essa é uma seção de tecnologia da news experimental, siga essa news também no linkedin & você pode se desinscrever dessa seção e se manter nas outras se quiser (:
01 de março de 2026
em ciência da computação só tem duas coisas difíceis:
0_ invalidação de cache;
1_ dar nomes às coisas;
2_ erros de ‘um por um’.
não sei de quem é essa piada, mas acho que todo dev já ouviu alguma versão dela 😂
vamos nomear algumas coisas hoje! vamos de monolito, monorepo, microserviços e o porquê isso importa mais agora em tempos de IA.
bora lá (:
git diff: monolito, monorepo e microserviços
monolito é quando toda a sua aplicação é uma coisa só. um backend que faz tudo, um deploy que sobe tudo junto, um processo que roda tudo. se uma parte quebra, o resto pode ir junto. imagina um restaurante onde o mesmo funcionário atende, cozinha, lava a louça e faz o caixa. funciona quando é pequeno. quando cresce, complica.
microserviços é o contrário. você pega aquele restaurante e divide: um time só cozinha, outro só atende, outro cuida do caixa. cada um funciona de forma independente, se comunica com os outros por mensagens (APIs, filas, eventos), e pode ser atualizado ou escalado separado. se o caixa quebra, a cozinha continua funcionando. a complexidade vai pra outro lugar, a comunicação entre esses serviços, mas cada peça é menor e mais fácil de entender sozinha.
monorepo é só onde você guarda o código. é uma decisão de organização, não de arquitetura. o repositório é a gaveta. o que você coloca dentro é outra conversa.
grandes empresas como Google e Meta trabalham com monorepos. o Google guarda uma quantidade absurda de código num repositório único, mas dentro desse repositório tem milhares de serviços independentes. ou seja: monorepo (organização) e microserviços (arquitetura) são decisões independentes. você pode combinar qualquer uma com qualquer outra.
monorepo facilita compartilhar código entre times, manter dependências consistentes e fazer mudanças que afetam vários serviços de uma vez. é mais fácil refatorar quando tudo tá no mesmo lugar do que quando você precisa abrir pull request em 15 repositórios diferentes.
então por que empresas menores costumam separar em vários repositórios?
primeiro, porque monorepo em escala grande exige tooling pesado, CI/CD sofisticado*, e processos que times pequenos geralmente não precisam. pra um time de 3 pessoas, ter um repositório por serviço pode ser mais simples.
segundo, e esse é um ponto que passa despercebido: permissão de acesso. se você contrata um dev freelancer pra mexer só no front, com repositórios separados você dá acesso só àquele repo. num monorepo, a pessoa tem acesso a tudo, scraper, lógica de negócio, infra, chaves de API que alguém esqueceu de colocar no .env...
o controle de acesso é um dos principais motivos pelos quais os multirepositórios ainda são populares, porque não há solução para controle de acesso em monorepositórios.
___
commit na main
a gente gasta muito tempo tentando encaixar o que constrói em categorias que foram pensadas pra contextos completamente diferentes. monolito vs. microserviços é um debate que faz sentido quando você tem 20 devs e deploys diários. quando é você e seu café às 23h, a pergunta é outra: consigo manter isso? consigo voltar pro código depois de uma semana focada em outro freela e entender o que tá acontecendo?
e tem gente levando essa simplicidade ao extremo faz tempo. o Pieter Levels, que construiu o Nomad List e o RemoteOK, roda produtos com milhões de usuários numa estrutura ridiculamente simples: um arquivo PHP, um servidor, jQuery no front. o Marc Lou faz algo parecido com Next.js. nada de microserviços, nada de orquestração. complexidade mínima necessária pra resolver o problema e seguir em frente.
não quer dizer que essa é a resposta certa pra todo mundo. mas quando um dev solo faturando alto usa uma arquitetura que um estagiário entenderia, talvez a gente devesse ser humilde de entender que muito do que a gente aprende na faculdade e trabalhando pra grandes empresas é, na real, opcional.
tem muitas formas de construir uma casa. com engenheira e arquiteta, só com mestre de obras, até um grupo construindo uma eco vila. muda o material, a técnica, a manutenção... mas no fim o importante é a casa construída e servindo aos moradores. software é a mesma coisa.
___
git cherry-pick: IA lê melhor quando o código tá junto
quando o contexto do projeto inteiro tá no mesmo lugar, a IA consegue navegar entre os serviços. entender como o scraper alimenta o banco, como o banco alimenta o front, e sugerir mudanças que fazem sentido pro sistema inteiro.
com repositórios separados, a IA só enxerga o pedaço que você abriu. é como pedir conselho pra alguém que só leu o capítulo 3 do livro. a pessoa até tenta ajudar, mas falta contexto.
as ferramentas que a gente usa pra codar estão mudando rápido, e a forma como organizamos o código precisa acompanhar. não é mais só sobre legibilidade pra humanos. é sobre legibilidade pra humanos e pra IA ao mesmo tempo.
um aviso: IA é copiloto, não piloto automático. a velocidade de aprendizado aumenta muito quando você trata cada sugestão como ponto de partida pra entender, não como resposta final.
___
git rebase: juntando tudo num lugar só
resolvi adotar o monorepo pro buscador de leilões. em algumas horas juntei tudo num repositório só: scraper, leitor de matrículas e front. organizado com pnpm workspaces, que é uma forma de ter vários “projetos” no mesmo repo, cada um com suas dependências, mas linkados entre si. pensa numa casa com quartos independentes que compartilham a mesma cozinha.
e foi com essa visão de contexto completa que a bagunça apareceu rápido. com acesso a todas as peças do quebra-cabeça, a IA apontou coisas que eu sozinha ia demorar pra notar.
tinha scripts apontando pra arquivos que não existiam. referências no package.json pra código que ainda não tinha sido escrito. e o pior: eu tinha um package.json tentando fazer tudo, subir o servidor, rodar scrapers, processar PDFs, geocodificar endereços. era o equivalente técnico daquele funcionário do restaurante que atende, cozinha, lava louça e faz o caixa. lembra dele lá de cima? pois é.
arrumando a bagunça, olhei pro resultado e pensei: isso aqui é um monolito?
não. cada serviço tem seu próprio package.json, suas próprias dependências, seu próprio tsconfig. o scraper roda no próprio schedule com node-cron. o leitor de matrículas exporta uma função: recebe URL de PDF, devolve dados estruturados, e acabou. a API sobe separada. são processos independentes que moram no mesmo endereço. monorepo, mas não monolito.
e aqui tá o ponto que vai além de monorepo vs. multi-repo: distribuir o sistema em serviços separados não resolve confusão. só espalha. se você não consegue definir limites claros dentro de um repositório só, criar quinze repositórios não vai magicamente trazer essa clareza. a bagunça só fica mais difícil de encontrar.
___
git diff: como as peças se conectam sem se conhecer
em microserviços de verdade, os serviços se comunicam por HTTP, filas e eventos. aqui a integração é mais simples: o banco de dados.
o scraper escreve no Supabase. a API lê do Supabase. o leitor de matrículas processa o PDF e devolve os dados pra quem chamou, sem escrever em lugar nenhum. cada peça só conhece o banco. nenhuma peça conhece as outras.
é microserviço no sentido formal? não. é monolito? também não. é algo no meio. e pra uma dev solo construindo produto, esse “no meio” é exatamente onde eu preciso estar. microserviços formais iam significar deploy separado, filas, orquestração, e cada erro ia custar três vezes mais pra debugar. pra um time de uma pessoa, isso é overhead que não volta em valor nenhum.
não tô no meio porque sou pequena demais pra fazer “direito”. tô no meio porque é o lugar onde tenho mais clareza. e clareza, pra quem constrói sozinha, é o recurso mais valioso que existe.
____
outras branches
tenho conhecido muitas pessoas que nunca codaram antes e estão arriscando agora com IA, meio que vibe coding, meio que não... de qualquer forma é muito legal ver designers e pessoas de produto dando seus primeiros deploys com esse brilho nos olhos de quem acabou de colocar algo no ar pela primeira vez.
semana passada fui co-host de uma sessão de co-building com IA em Ho Chi Minh City, o “Ship Happens”.
a ideia:
3 horas focadas construindo junto, com timer. antes de começar, todo mundo fala pras pessoas da mesa quais os objetivos do bloco de tempo, e cada um trabalha no seu projeto em silêncio. nos intervalos, troca de ferramentas e feedback.
no final, mini pitch de 2 minutos pra quem quiser mostrar o que fez. todos os níveis, inclusive quem nunca abriu um terminal. [link]
e pra semana que vem... bora organizar na sua cidade mini eventos tech pro dia das mulheres? aqui o evento que vou ser co-host em Ho Chi Minh pra você se inspirar. [link].
Até o próximo commit, Michelle (:
__
*CI/CD é o que acontece entre você dar git push e o código estar rodando em produção. CI (continuous integration) é a parte automática que roda depois do push: um servidor (tipo GitHub Actions) instala as dependências, roda os testes, verifica se o código compila. se alguma coisa falha, você recebe um aviso antes de qualquer coisa ir pro ar. CD (continuous deployment) é o passo seguinte: se o CI passou, o deploy acontece automaticamente.
se você usa Vercel pro front, já tem CD funcionando sem perceber, toda vez que faz push na main a Vercel faz build e sobe. o que provavelmente falta é o CI rodando testes antes de deixar o deploy acontecer. sem isso, se o código tiver um bug, ele vai pro ar e você descobre quando abre o site (ou pior, quando um usuário descobre). com CI, o deploy só acontece se os testes passaram. é uma rede de segurança automática. o custo é escrever os testes, que é onde a maioria das pessoas empaca, mas o CI em si é só um arquivo de configuração no repositório. (: