Arquitetura fora do padrão: como mantive meu projeto no ar sem uma VPS parruda
Quero compartilhar um pouco dos bastidores do Nave Ideal, um projeto pessoal que estou desenvolvendo, e principalmente uma decisão de arquitetura que foge bastante do “padrão recomendado”.
Não foi por genialidade. Foi por necessidade mesmo.
Desde o início eu sabia que o coração do projeto seria web scraping. E quem já trabalhou com isso sabe: scraping consome CPU, múltiplas abas abertas, validações de página, timeout, retry, etc.
No começo pensei: “Beleza, coloco tudo numa VPS e resolvo.”
Só que não.
Uma VPS capaz de rodar scraping pesado não é barata e, no estágio inicial do projeto, simplesmente não fazia sentido investir pesado em infraestrutura. Fui então otimizando o código aos poucos: reduzi consumo de memória, controlei concorrência, fechei páginas corretamente e melhorei o tempo de execução. Hoje o bot consome bem menos do que no início, mas mesmo assim rodar isso em uma VPS simples continuaria sendo um gargalo — ou um risco real de queda.
Foi aí que surgiu a pergunta que mudou tudo:
“E se o bot cair… o site precisa cair junto?”
A resposta foi clara: não.
O scraping é importante, mas o site precisa continuar no ar, buscando anúncios já indexados, respondendo usuários, validando links antigos e enviando alertas no WhatsApp. Foi nesse momento que decidi separar completamente as responsabilidades.
Hoje o projeto funciona assim:
Front-end (Vercel): o front é estático, rápido e barato de manter. A Vercel resolve cache, CDN e deploy sem dor de cabeça.
Back-end (VPS): na VPS ficam a API, o banco de dados, o validador de links (que remove anúncios que não existem mais) e toda a parte crítica que precisa ficar sempre disponível. Mesmo com uma VPS modesta, isso roda tranquilo.
Bot de scraping (local): o scraping roda na minha máquina local, direto no terminal. Isso resolve vários problemas de uma vez: posso usar CPU à vontade, o Puppeteer abre várias abas sem matar o servidor, se o bot parar o site continua funcionando, e posso pausar, testar e evoluir o bot sem impactar os usuários. Na prática, o bot virou um fornecedor de dados, não um ponto único de falha.
A pergunta que normalmente vem depois é:* “Mas isso é escalável?”*
Hoje? Não totalmente. E tudo bem.
Essa arquitetura não nasceu para ser perfeita, nasceu para viabilizar o projeto. Ela me permitiu colocar o site no ar, validar a ideia, reduzir custos e aprender muito mais sobre limites reais de infraestrutura.
No futuro, quando fizer sentido financeiro, o bot pode ir para workers, filas, containers, VPS dedicada ou qualquer outra solução mais robusta. Mas antes disso, o produto precisava existir.
O principal aprendizado foi simples: arquitetura bonita no papel é fácil. Arquitetura que cabe no bolso e resolve o problema agora é outra história. Essa solução não veio de livro nem de curso. Veio de errar, medir consumo, ver a VPS sofrer e pensar: “Ok, como eu faço isso funcionar com o que eu tenho hoje?”
Se você está começando um projeto e sente que “não pode” porque a arquitetura ideal é cara, talvez dê para pensar diferente. Nem sempre o padrão é o melhor caminho, às vezes ele só não cabe na realidade do momento.