Mini site de documentaçãoDeveloper Atlas

Entrada rápida para navegar arquitetura, APIs, operação e guias técnicos do projeto sem depender da estrutura do repositório.

44 notas

Procure por módulo, API, rota, fluxo operacional ou termo do projeto.

Base do projeto/docs/roadmap-de-plataforma-e-escalabilidade

Roadmap de Plataforma e Escalabilidade

Transformar o ecossistema atual em uma plataforma proprietária capaz de sustentar:

Recorte da seçãoBase estrutural do projeto

Nota de referência para contratos, arquitetura, runbook e organização do workspace. É a camada mais estável da documentação.

Atualizado19 de mar. de 2026
Seções21
Tags4
roadmapescalabilidadevpsmobile

Objetivo deste ciclo

Transformar o ecossistema atual em uma plataforma proprietária capaz de sustentar:

  • storefront web performático;
  • painel administrativo com operação segura;
  • CMS/blog integrado ao e-commerce;
  • catálogo, carrinho, checkout e promoções;
  • aplicativo mobile consumindo a mesma base e os mesmos contratos.

Este resumo traduz o plano de docs/IMPLEMENTATION_ROADMAP.md para o mini site, com foco no que vamos construir na prática.

Princípios de decisão

  • começar em infraestrutura própria, dentro de uma VPS dedicada;
  • evitar lock-in desde o início;
  • separar leitura pública de escrita operacional;
  • manter contratos estáveis para web, painel e mobile;
  • usar cache agressivo na leitura e consistência forte na escrita;
  • preparar migração gradual do JSON atual para banco sem desmontar a UI já pronta.

Stack recomendada para a fase VPS-first

  1. Next.js para o EcommPanel e o storefront web.
  2. TypeScript + Fastify para o backend dedicado quando entrarmos na camada transacional.
  3. PostgreSQL como fonte principal de verdade.
  4. Redis para cache, sessão, rate limit e filas leves.
  5. MinIO ou storage compatível com S3 para mídia e anexos.
  6. PgBouncer para aliviar conexões ao banco.
  7. Docker Compose para subir a plataforma inteira na VPS sem custo adicional de serviço gerenciado.
  8. Caddy ou Nginx como reverse proxy, TLS, compressão e cache básico de borda.
  9. Prometheus, Grafana e Loki como base open source de métricas, logs e observabilidade.

O que continua válido agora

O projeto atual já tem ativos importantes que não precisam ser descartados:

  • EcommPanel como centro operacional;
  • builder de páginas e blog como camada editorial;
  • analytics interno;
  • API pública v1 como contrato inicial para leitura;
  • runtime publicado via snapshots como etapa intermediária antes do banco.

Em outras palavras: a próxima arquitetura não substitui a base atual do zero. Ela evolui a plataforma em camadas.

Como a VPS entra no plano

Fase inicial

Uma única VPS consegue hospedar a primeira versão completa da plataforma, desde que tudo suba em serviços separados e com responsabilidades claras.

Serviços esperados nessa etapa:

  • ecommpanel
  • storefront
  • api
  • worker
  • postgres
  • pgbouncer
  • redis
  • minio
  • caddy ou nginx

Capacidade orientativa da VPS atual

Para uma VPS pequena de entrada, na faixa de 1 vCPU, 4 GB RAM e disco local, a capacidade real varia muito conforme o tipo de tráfego.

Leitura prática:

  • se a maior parte do tráfego estiver em páginas cacheáveis, conteúdo estático e assets já aquecidos, a loja pode atender algumas centenas de conexões abertas sem entrar em colapso;
  • se o tráfego for de navegação normal com páginas, busca, carrinho e algumas áreas dinâmicas, a expectativa mais prudente fica próxima de 100 usuários realmente ativos ao mesmo tempo;
  • se houver muito SSR, consulta transacional, busca pesada, checkout concorrente e administração simultânea, esse teto cai rapidamente.

Em termos de planejamento, a leitura conservadora para a fase inicial é:

  1. 100 usuários simultâneos é uma meta plausível para operação inicial com bastante cuidado de cache.
  2. 500 usuários simultâneos só faz sentido se a maior parte estiver em leitura muito leve, com forte cache e pouca carga dinâmica.
  3. 10 mil usuários simultâneos não devem ser tratados como meta realista para esse porte de VPS sem borda externa, cache distribuído e separação robusta de serviços.

Essa capacidade não deve ser lida como benchmark fechado. Ela é uma régua de planejamento para não superestimar a infraestrutura atual.

Fase de crescimento

Quando tráfego, escrita concorrente e mídia aumentarem, a migração natural será:

  1. separar banco e cache da máquina que serve as aplicações;
  2. colocar a mídia em storage dedicado;
  3. manter painel, web e mobile falando com a mesma API;
  4. adicionar borda externa para CDN, WAF e mitigação volumétrica.

Banco dedicado do produto

O novo domínio do produto não deve reaproveitar os bancos já existentes da máquina atual.

Direção adotada:

  • criar instâncias dedicadas para PostgreSQL, PgBouncer, Redis e storage do produto;
  • manter EcommPanel, storefront e futura API falando com essa camada própria;
  • deixar o ambiente replicável localmente e em outra VPS com a mesma estrutura de Docker Compose.

Isso reduz acoplamento, evita mistura com serviços legados e facilita a futura separação entre aplicação e dados.

Ordem macro de implementação

Etapa 1

Consolidar o que já existe no monorepo:

  • painel operacional;
  • blog;
  • analytics;
  • API pública v1;
  • documentação navegável e runbook.

Etapa 2

Abrir a fundação de plataforma:

  • docker-compose do ambiente;
  • backend dedicado;
  • banco, cache e storage local;
  • healthchecks, logs e backups.

Etapa 3

Migrar o domínio crítico para persistência real:

  • autenticação;
  • RBAC;
  • auditoria;
  • catálogo;
  • inventário;
  • carrinho;
  • pedidos.

Etapa 4

Fechar performance e concorrência:

  • projeções de leitura;
  • invalidação de cache;
  • idempotência de checkout;
  • controle transacional de estoque;
  • filas e tarefas assíncronas.

Etapa 5

Ampliar o domínio comercial:

  • promoções;
  • cupons;
  • gift cards;
  • regras por categoria, coleção, canal e região.

Etapa 6

Abrir oficialmente a frente mobile:

  • app em Flutter;
  • autenticação reaproveitando o backend;
  • catálogo, ofertas e checkout no mesmo contrato do web;
  • backend pronto para atender loja, painel e aplicativo.

Segurança e escala

Há duas camadas diferentes de preocupação:

Camada que resolvemos agora

  • RBAC;
  • auditoria;
  • rate limit;
  • sessão com expiração;
  • logs estruturados;
  • backups;
  • isolamento por serviço;
  • hardening básico da VPS.

Camada que provavelmente exigirá borda externa depois

  • mitigação forte de DDoS volumétrico;
  • CDN global;
  • WAF gerenciado em larga escala.

Ou seja: dá para operar bastante coisa com VPS própria e stack open source, mas o plano já nasce preparado para migrar partes da borda quando o volume justificar.

Resultado esperado

Ao final deste roadmap, a empresa passa a ter:

  • um backoffice próprio;
  • um storefront web desacoplado;
  • uma API estável para integrações;
  • base pronta para aplicativo mobile;
  • arquitetura que começa enxuta, mas não precisa ser refeita para crescer.

Leitura seguinte