De uma Raspberry Pi, a uma arquitetura híbrida em nuvem: a evolução do meu pipeline de automação

Eu comecei esse projeto como muitos projetos técnicos começam: com o que eu tinha disponível.

Uma Raspberry Pi (com 1Gb de RAM e 32GB de Micro SD 😪) rodando um pipeline de scraping, processamento de dados e distribuição de ofertas. Simples, funcional e suficiente para o estágio inicial. Durante um bom tempo, atendeu perfeitamente.

Mas conforme o volume aumentou e a necessidade de confiabilidade ficou mais evidente, comecei a perceber três limitações claras:

• Dependência de infraestrutura doméstica
• Risco de indisponibilidade por fatores externos (energia, internet)
• Gargalos de performance em tarefas mais pesadas

Foi nesse momento que decidi evoluir a arquitetura.

A decisão arquitetural

O objetivo não era apenas “migrar para a nuvem”.

Era redesenhar o fluxo pensando em:

• Separação de responsabilidades
• Escalabilidade sob demanda
• Observabilidade
• Eficiência de custos

A solução final acabou se tornando uma arquitetura híbrida e distribuída, combinando GitHub Actions com uma VPS na Oracle Cloud (Always Free), como mostra a imagem abaixo:

Arquitetura do projeto

1. Processamento como workload efêmero

O primeiro passo foi retirar o processamento pesado da Raspberry Pi.

O scraping com Playwright, parsing, tratamento e geração das mensagens agora rodam em GitHub Actions.

Na prática, transformei o pipeline em um modelo próximo de serverless orientado a eventos agendados. O job executa de hora em hora, provisiona o ambiente, roda o processamento e é destruído ao final.

• Benefícios técnicos claros:
• Ambiente limpo a cada execução
• Escalabilidade automática conforme necessidade
• Redução de estado residual
• Eliminação de gargalos de hardware local

Além disso, todas as credenciais sensíveis são gerenciadas via GitHub Secrets, garantindo isolamento e aderência a boas práticas de segurança.

2. Gateway resiliente em nuvem

Para desacoplar o processamento da camada de entrega, implementei uma VPS na Oracle Cloud atuando como gateway de API (Evolution API).

Essa VPS:

• Mantém sessão persistente com os serviços de mensageria
• Centraliza integrações
• Funciona como ponto estável de comunicação

Mesmo que o pipeline de scraping falhe em uma execução específica, a camada de entrega permanece isolada e operacional.

Essa separação trouxe um ganho importante de resiliência arquitetural.

3. Persistência enxuta e orientada a versionamento

Uma das decisões mais interessantes foi evitar overengineering.

Em vez de introduzir um banco de dados tradicional logo no início, utilizei o próprio Git como mecanismo de persistência de estado.

O pipeline realiza commits automáticos para:

• Atualizar catálogo de ofertas já processadas
• Controlar deduplicação
• Manter histórico auditável

Além de simples, essa estratégia trouxe rastreabilidade nativa e versionamento automático do estado da aplicação.

Para o volume atual, é uma solução eficiente e suficientemente robusta.

4. Observabilidade e monitoramento

Nenhuma arquitetura é confiável sem visibilidade.

Implementei monitoramento ativo com alertas via Telegram para:

• Disponibilidade da VPS
• Saúde da API
• Falhas de execução do pipeline

Isso transformou o projeto de algo “que roda” para algo “operacionalmente observável”.

Ainda não é um sistema totalmente self-healing, mas é transparente e rapidamente recuperável.

O resultado arquitetural

Hoje tenho um pipeline que:

• Executa de hora em hora
• Opera 24/7
• Não depende de infraestrutura local
• É resiliente a falhas pontuais
• Roda majoritariamente em camadas gratuitas

Saí de um setup monolítico em hardware doméstico para uma arquitetura distribuída, desacoplada e orientada a eventos.

Principais aprendizados técnicos:

1. Escalabilidade não começa com mais CPU, começa com melhor arquitetura.
2. Separar processamento de entrega aumenta drasticamente a resiliência.
3. Nem sempre um banco de dados é a primeira resposta correta.
4. Observabilidade deve nascer junto com a arquitetura, não depois.
5. É possível aplicar princípios de DevOps, DevSecOps e FinOps mesmo em projetos pessoais.

Essa evolução não foi apenas uma migração de infraestrutura. Foi uma mudança de mentalidade arquitetural.

Próximos passos: transformando automação em inteligência operacional

Se até aqui o foco foi resiliência e escalabilidade, o próximo passo é transformar o pipeline em uma camada de inteligência.

Quero evoluir o projeto para integrar métricas diretamente das APIs do Mercado Livre e da Shopee, consumindo dados como:

• Volume de vendas por período
• Conversão por produto
• Receita acumulada
• Ticket médio
• Performance por categoria
• Taxas e comissões

A ideia é consolidar esses dados em uma camada analítica própria, estruturando um mini data mart orientado a métricas de vendas.

Mas o ponto mais interessante é a interface.

Automação por voz com Alexa

Quero expor esses relatórios via integração com Alexa, permitindo consultas por voz como:

• “Qual o relatório de vendas Shopee dos últimos 7 dias?”
• “Qual foi o faturamento do Mercado Livre ontem?”
• “Qual produto teve maior conversão na última semana?”

Tecnicamente, isso significa:

• Criar uma skill personalizada na Alexa
• Expor um endpoint seguro para consulta
• Implementar agregações pré-calculadas para reduzir latência
• Garantir autenticação e controle de acesso

Esse movimento transforma o projeto de um pipeline de automação para um sistema de consulta inteligente orientado a dados.

Outras evoluções possíveis

Além da camada de voz, existem algumas melhorias estratégicas que estão no radar:

1. Camada analítica estruturada

Migrar a persistência para um modelo híbrido, mantendo o Git para controle de estado, mas adicionando um banco analítico (PostgreSQL ou DuckDB) para consultas históricas mais complexas.

2. Dashboard operacional

Criar um painel de observabilidade com métricas de:

• Latência de execução do pipeline
• Taxa de sucesso por execução
• Volume de ofertas processadas
• Métricas de vendas consolidadas

Isso permitiria acompanhar saúde operacional e performance comercial no mesmo lugar.

3. Cache inteligente e agregações

Implementar pré-processamento diário/semanal para gerar relatórios prontos para consumo, reduzindo carga nas APIs externas e melhorando tempo de resposta.

4. Evolução para arquitetura orientada a eventos

Migrar parte do fluxo para um modelo orientado a eventos (webhooks ou fila), reduzindo dependência de agendamentos fixos e tornando o sistema mais reativo.

5. Self-healing real

Adicionar health checks automatizados e rotinas de restart controlado da VPS e dos containers, evoluindo de observável para realmente auto-recuperável.

O projeto começou como automação de ofertas.

Hoje ele já é uma arquitetura distribuída.

O próximo passo é torná-lo uma plataforma de inteligência comercial acionável — onde dados não apenas circulam, mas respondem.

E dessa vez, por voz.

Caso queiram particpar de algum dos grupos, segue o link das redes sociais:

https://linktr.ee/achadinhosdodev

Sucesso e foco nos estudos!

#EngenhariaDeSoftware #EngenhariaDeDados #ArquiteturaDeSoftware #CloudComputing #Serverless #DevOps #DevSecOps #FinOps #GitHubActions #OracleCloud #Python #Automacao #SistemasDistribuidos #Observabilidade #Data #DataEngineer