Roadmap - VPS Escala e Mobile

Objetivo do guia

Registrar a ordem prática de execução para sair do monorepo atual e chegar a uma plataforma com:

• painel administrativo;
• storefront web;
• backend dedicado;
• base única de dados;
• capacidade de expansão para app mobile.

Premissa operacional

O primeiro ciclo deve caber em uma VPS dedicada, sem depender de serviços pagos obrigatórios.

Ao mesmo tempo, cada parte precisa nascer desacoplada o suficiente para migrar depois para serviços maiores sem reescrever o produto.

Onda 1 - Fechar a base atual do monorepo

Objetivo:

• consolidar o que já existe antes de trocar a persistência.

Entregas:

1. EcommPanel operacional.
2. Blog com publicação e moderação.
3. Analytics interno.
4. API pública v1.
5. Home dinâmica opcional.
6. Documentação e runbook claros.
7. Primeira versão de Minha conta no storefront.

Critério de saída:

• o painel consegue operar conteúdo, tema, blog, analytics e publicação com previsibilidade;
• o storefront já expõe a primeira camada de relacionamento com o cliente para pedidos, dados e endereços.

Onda 2 - Subir a plataforma completa na VPS

Objetivo:

• trocar a execução ad hoc por serviços claros, versionáveis e reproduzíveis.

Stack recomendada:

1. Docker Compose
2. Caddy ou Nginx
3. Next.js para ecommpanel
4. Next.js para storefront
5. Fastify para api
6. worker para tarefas assíncronas
7. PostgreSQL
8. PgBouncer
9. Redis
10. MinIO

Entregas:

1. compose para desenvolvimento e VPS.
2. Volumes persistentes para banco, cache e mídia.
3. TLS, gzip/brotli e roteamento por subdomínio.
4. Healthchecks por serviço.
5. Backup inicial de banco e mídia.

Capacidade de partida esperada

Para uma VPS pequena de entrada, com 1 vCPU e aproximadamente 4 GB RAM, a expectativa correta não é pensar em grande escala logo de saída.

Cenários de leitura:

1. páginas estáticas, assets e conteúdo muito cacheável: algumas centenas de conexões abertas podem coexistir bem;
2. navegação real de loja com cache razoável: cerca de 100 usuários simultâneos ativos é uma meta prudente;
3. busca, checkout, estoque e administração em cima da mesma máquina: o limite cai rápido e a latência sobe cedo;
4. 500 usuários simultâneos só entram como cenário parcialmente cacheado e com baixa pressão de escrita;
5. 10 mil usuários simultâneos não entram como premissa de arquitetura para essa faixa de VPS.

Essa estimativa existe para orientar expectativa e ordem de investimento, não para substituir benchmark de carga.

Decisão de banco dedicado

O banco do produto não será instalado em cima dos bancos já usados por outros serviços da VPS.

A diretriz é:

1. banco novo e dedicado para o ecossistema EcommPanel + storefront + futura API;
2. cache dedicado;
3. storage dedicado;
4. mesma topologia no local e na VPS.

Na prática, isso significa que uma segunda VPS com a mesma configuração já melhora bastante a entrada em produção quando ela for usada para isolar dados e cache.

Onda 3 - Fundamento de dados e segurança

Objetivo:

• sair do mock operacional e entrar em persistência confiável.

Primeiros domínios a migrar:

1. users
2. sessions
3. roles
4. audit_logs
5. catalog_products
6. catalog_skus
7. catalog_categories
8. catalog_collections
9. customer_accounts
10. customer_addresses
11. customer_orders

Primeiras garantias obrigatórias:

• migration versionada;
• seed inicial;
• RBAC persistido;
• trilha de auditoria;
• sessão expirada por servidor;
• ações críticas com registro rastreável.

Frente em andamento: Minha conta

A área do cliente entrou primeiro como uma camada local de transição para não travar a UX enquanto o backend dedicado ainda não está fechado.

Estado atual:

1. rota pública /e-commerce/minha-conta;
2. sessão local por e-mail neste navegador;
3. histórico inicial alimentado pelo checkout;
4. pedido operacional já separado da simples projeção da conta;
5. dados pessoais e endereços já estruturados em contrato próprio.

Próxima evolução:

1. autenticação real de cliente;
2. persistência em PostgreSQL;
3. leitura de pedidos por API;
4. rastreio público por token e fila administrativa já compatíveis com mobile no backend;
5. base pronta para reaproveitamento no app mobile.

Onda 4 - Catálogo, estoque e checkout com concorrência

Objetivo:

• impedir divergência entre sessões e sustentar compra real.

Regras estruturais:

1. leitura pública pode usar cache;
2. escrita crítica não depende de cache;
3. estoque e pedido precisam passar por transação;
4. checkout precisa de idempotência;
5. reserva de estoque precisa de expiração e reconciliação.

Entregas:

1. CRUD administrativo de produto, SKU, categoria e coleção.
2. Módulo de mídia por produto.
3. Preço e disponibilidade por SKU.
4. Carrinho server-side.
5. Checkout transacional.
6. Pedido com status e histórico.

Estado atual desta onda

Já entrou:

1. operação administrativa de catálogo;
2. mídia e presets de imagem;
3. contrato de produto ampliado;
4. draft e consolidação de pedido;
5. fila operacional de pedidos;
6. área do cliente com pedidos e endereços.

Ainda falta fechar:

1. estoque por origem;
2. seller/loja/centro de distribuição;
3. docas e regras de expedição;
4. SLA e regionalização por CEP ou geolocalização;
5. escolha da melhor oferta ou da oferta desejada por origem;
6. UX final do checkout com simulação logística mais inteligente.

Onda 5 - Performance de leitura

Objetivo:

• manter painel e storefront rápidos ao mesmo tempo.

Estratégia recomendada:

Painel

• no-store;
• leitura do dado mais recente;
• foco em consistência operacional.

Storefront e mobile

• read models;
• cache HTTP;
• Redis;
• invalidação por publish, preço, estoque e promoção.

Busca

Começar com o próprio PostgreSQL e índice textual.

Abrir OpenSearch depois quando filtros, volume e relevância justificarem a nova peça.

Onda 6 - Segurança de produção e operação em VPS

Objetivo:

• reduzir risco antes de escalar horizontalmente.

Medidas recomendadas sem custo obrigatório:

1. UFW ou firewall equivalente.
2. Fail2ban.
3. rate limiting no proxy e na API.
4. cabeçalhos de segurança.
5. webhook assinado.
6. segredos fora do repositório.
7. observabilidade com Prometheus, Grafana e Loki.
8. rotina de backup testada.

Observação importante:

Essas medidas ajudam muito contra abuso de aplicação e tráfego descontrolado, mas não substituem proteção de borda forte para DDoS volumétrico. Quando o tráfego crescer, o próximo passo natural é adicionar uma camada externa de CDN e WAF.

Onda 7 - Módulos comerciais avançados

Objetivo:

• fechar o domínio que sustenta a loja como produto real.

Entradas principais:

1. promoções por regra;
2. cupons;
3. gift cards;
4. logística por região;
5. preferências do cliente;
6. conta do cliente;
7. histórico de pedidos e recompra.

Frente logística antes de promoções

Na prática, existe uma frente que deve ser aberta antes do bloco promocional completo:

1. malha logística com origem de estoque;
2. marketplace com múltiplas lojas ou sellers;
3. sortimento condicionado por região;
4. prazo e custo de entrega calculados por origem.

Essa camada alimenta diretamente:

• PDP;
• PLP;
• carrinho;
• checkout;
• futura experiência mobile.

Sem isso, o pagamento até pode ser integrado, mas a compra ainda não estará modelada com inteligência comercial suficiente.

Onda 7.5 - Pagamentos e ciclo financeiro

Objetivo:

• conectar o pedido operacional já consolidado a um fluxo financeiro real.

Entregas:

1. adapter de gateway de pagamento;
2. ambiente sandbox inicial;
3. endpoint de webhook assinado;
4. atualização de status financeiro no pedido;
5. conciliação mínima e rastreio de eventos de pagamento;
6. base pronta para múltiplos meios de pagamento depois.

Dependências:

• pedido operacional consolidado;
• checkout mais estável;
• definição mínima da camada logística e da oferta final.

Onda 8 - App mobile em Flutter

Objetivo:

• entregar um cliente multiplataforma usando a mesma plataforma do web.

Direção recomendada:

1. Flutter como cliente mobile.
2. Mesmo backend usado por EcommPanel e storefront.
3. Mesmo banco de dados.
4. Mesmo domínio de autenticação, catálogo, oferta, carrinho e pedido.

O aplicativo não deve depender do código React do web. Ele deve depender da mesma plataforma.

Contratos que precisam permanecer estáveis

Para a expansão funcionar sem retrabalho, estes contratos precisam ser tratados como produto:

1. autenticação e sessão;
2. catálogo e preço;
3. disponibilidade e estoque;
4. carrinho e checkout;
5. conteúdo editorial;
6. analytics e eventos;
7. promoções e benefícios.

Critérios para sair da VPS única

Sinais de que a arquitetura precisa ser separada:

1. CPU sustentada alta durante picos.
2. disputa de I/O entre aplicação e banco.
3. backlog crescente em filas.
4. latência do banco sob carga concorrente.
5. crescimento forte de mídia.
6. necessidade real de borda global.

Quando isso acontecer, a migração fica mais simples se já estivermos com:

• serviços separados;
• banco isolável;
• cache isolável;
• storage compatível com S3;
• API estável;
• observabilidade pronta.

Leitura seguinte

• 11 - Roadmap de Plataforma e Escalabilidade
• 29 - Snapshot de Cobertura e Maturidade
• 16 - API Publica v1 e Cache
• 07 - Runbook Rapido