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.

Critério de saída:

• o painel consegue operar conteúdo, tema, blog, analytics e publicação com previsibilidade.

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

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.

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.

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.

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
• 16 - API Publica v1 e Cache
• 07 - Runbook Rapido