Arquitetura.md

-| [Home](Home) | [**Escopo**](Escopo) | [Processo](Processo) | [Sprints](Sprints) | [Design](Design) | [Arquitetura](Arquitetura) | [Repositórios](Repositórios) | [Banco de Dados](Banco de Dados) |
-| :----------: | :-------------------------------: | :------------------: | :--------------: | :--------------------------: | :--------------------: | :------------------------: | :--------------: |
+# Arquitetura
+
+| [Home](Home) | [Escopo](Escopo) | [Processo](Processo) | [Sprints](Sprints) | [Design](Design) | [**Arquitetura**](Arquitetura) | [Repositorios](Repositorios) | [Gerencia](Gerencia) | [Banco de Dados](Banco-de-Dados) |
+| :----------: | :-------------------------------: | :------------------: | :--------------: | :--------------------: | :--------------------------: | :------------------------: | :---------------: | :--------------: |
 
 ## Descrição
+
 Esta seção irá abordar os detalhes sobre a arquitetura selecionada para o backend e frontend, além da informações relacionadas ao deploy.
 
 ## Sumário
 
- - [Arquitetura Geral da Aplicação](#arquitetura-geral-da-aplicação)
- - [Deploy](#deploy)
+- [Arquitetura Geral da Aplicação](#arquitetura-geral-da-aplicação)
+- [Deploy](#deploy)
+  - [Deploy Atual (AWS Simplificado - Produção)](#deploy-atual-aws-simplificado---produção)
+  - [Infraestrutura de Backup (Multi-Cloud - Standby)](#infraestrutura-de-backup-multi-cloud---standby)
   - [Diagrama de Deploy](#diagrama-de-deploy)
- - [AWS](#aws)
- - [Azure](#azure)
- - [Backend](#backend)
+- [AWS (Produção Atual)](#aws-produção-atual)
+  - [EC2](#ec2-compute---backend-e-serviços)
+  - [S3](#s3-static-hosting---frontend)
+  - [SES](#ses-e-mail-transacional---todo)
+- [Azure (Infraestrutura Backup - Standby)](#azure-infraestrutura-backup---standby)
+  - [VMs](#vms-compute---backup)
+  - [Blob Storage](#blob-storage-estado-terraform)
+- [Backend](#backend)
   - [Definições de Tecnologias](#definições-de-linguagem-e-bibliotecas)
-    - [Módulos do Sistema](#módulos-do-sistema)
-  - [Frontend](#frontend)
+  - [Módulos do Sistema](#módulos-do-sistema-backend)
+- [Frontend](#frontend)
   - [Definições de Tecnologias](#definições-de-tecnologias-e-bibliotecas)
-    - [Módulos do Sistema](#módulos-do-sistema­­­­)­­
+  - [Módulos do Sistema](#módulos-do-sistema---frontend)
 
 ## Arquitetura geral da aplicação
+
 Baseando-se no que foi planejado para o nosso banco de dados, levantamento dos requisitos e o entendimento geral do time sobre o projeto a ser desenvolvido, optamos por uma arquitetura de Cliente-Servidor, onde há uma separação entre o frontend e backend.
 
 O frontend é responsável por apresentar a interface ao usuário e interagir com o backend via chamadas de API. Já o backend por sua vez, gerencia a lógica de negócios, processamento de dados e interações com o banco de dados.
@@ -26,34 +37,115 @@ O frontend é responsável por apresentar a interface ao usuário e interagir co
 Além disso a estrutura conta com módulos que facilita a reutilização de código e melhor organização do projeto. Ao construirmos a arquitetura desta maneira permitimos uma escalabilidade maior, fácil manutenção e um desenvolvimento mais ágil para cada parte do sistema.
 
 ## Deploy
-Deploy é o processo de colocar no ar a aplicação pronta. No nosso fluxo, o código é construído em uma pipeline de CI/CD (Github Actions), que gera as imagens de backend, frontend, migrações e banco otimizado e publica tudo no Docker Hub. O Ansible então atualiza os clusters Docker Swarm em duas nuvens: AWS (EC2 em us-east-2/Ohio) e Azure (VMs em us-east-2). Na AWS usamos S3 para armazenamento e SES para e-mail; no Azure a infraestrutura é criada com Terraform, com o estado no Blob Storage. O tráfego é roteado pelo Traefik, a observabilidade fica com Prometheus/Grafana, e Metabase e Umami dão suporte a BI e analytics. A camada de domínio é gerenciada pela Cloudflare (com registros no registro.br), garantindo publicação automatizada, redundância multi-cloud e alta disponibilidade.
+
+### Deploy Atual (AWS Simplificado - Produção)
+
+O processo de deploy atual utiliza **GitHub Actions** (CI/CD) com **AWS** como provedor principal:
+
+**Pipeline CI/CD:**
+
+- **Trigger**: Merge em `main`
+- **Build**: Compilação TypeScript, testes (Jest/Vitest), lint
+- **Publicação**: Imagens Docker publicadas no **Docker Hub**
+- **Deploy**:
+  - **Frontend**: AWS S3 static hosting (TanStack Router - SPA)
+  - **Backend**: AWS EC2 (Ohio - us-east-2) com Docker containers
+  - **Database**: PostgreSQL (container na EC2)
+  - **Serviços**: Umami Analytics, Metabase BI (containers na EC2)
+
+**Motivação da arquitetura simplificada:**
+
+- Redução de complexidade operacional
+- Vantagens do S3 para Single Page Applications (React + TanStack Router)
+- Descentralização de conhecimento técnico (evitar bus factor)
+- Facilidade de manutenção para toda a equipe
+
+### Infraestrutura de Backup (Multi-Cloud - Standby)
+
+**Repositório:** <https://github.com/Saccilotto/pro-mata-infra> (pessoal - André Sacilotto Santos, AGES IV)
+
+**Stack Backup:**
+
+- **IaC**: Terraform (provisionamento Azure VMs / AWS EC2)
+- **CaC**: Ansible (configuração Docker Swarm)
+- **Orquestração**: Docker Swarm (balanceamento nativo)
+- **Proxy/LB**: Traefik v3 (reverse proxy + SSL Let's Encrypt)
+- **Observabilidade**: Prometheus + Grafana
+- **Multi-Cloud**: Azure VMs (state em Blob Storage) + AWS EC2 (state em S3)
+- **CDN/WAF**: Cloudflare
+- **Domínio**: registro.br
+
+**Status:**
+
+- **Standby**: Infraestrutura funcional, não utilizada em produção
+- **Ativação**: Configuração de variáveis de ambiente (< 4h para full deploy)
+- **Sincronização**: Consome imagens Docker Hub atualizadas automaticamente
+- **Propósito**: Redundância geográfica, tolerância a falhas, continuidade de negócio
+
+**Gestão de Riscos:**
+
+- Mitiga risco de falha crítica em infraestrutura AWS (probabilidade baixa, impacto alto)
+- Recovery Time Objective (RTO): < 4h
+- Trade-off documentado: simplicidade operacional vs. redundância ativa
 
 ### Diagrama de Deploy
+
 ![image](uploads/d0016fa7b84689d5cf6cb208de7c0ed2/image.png)
 
-## AWS
-A Amazon Web Services (AWS) compõe parte da infraestrutura em nuvem do ambiente produtivo. Nessa provedora são executadas instâncias EC2 que integram um cluster Docker Swarm, além de serviços de apoio, como S3 (armazenamento de objetos) e SES (e-mail transacional). A adoção da AWS prioriza elasticidade, disponibilidade e integração com serviços gerenciados.
+## AWS (Produção Atual)
+
+A **Amazon Web Services (AWS)** é o provedor de nuvem principal do ambiente produtivo. A arquitetura atual prioriza **simplicidade operacional** sobre redundância multi-cloud ativa.
+
+### EC2 (Compute - Backend e Serviços)
+
+- **Região**: us-east-2 (Ohio)
+- **Propósito**: Execução de containers Docker
+- **Serviços hospedados**:
+  - Backend (NestJS + Node.js 22)
+  - PostgreSQL 15 (containerizado)
+  - Umami Analytics
+  - Metabase BI
+- **Deploy**: Imagens Docker do Docker Hub (CI/CD GitHub Actions)
 
-### EC2
-O Amazon EC2 oferece capacidade de computação sob demanda para a execução dos contêineres. As instâncias participam de um Docker Swarm com balanceamento de carga nativo, permitindo escalar serviços como Backend, Webpage, Traefik, Prometheus, Grafana, Metabase e Umami conforme a demanda.
+### S3 (Static Hosting - Frontend)
 
-### S3
-O Amazon S3 é utilizado para armazenamento de objetos com alta durabilidade e versionamento, adequado para arquivos estáticos, mídias e artefatos do sistema, bem como para distribuição de conteúdo de baixa latência quando integrado à camada de borda.
+- **Propósito**: Hospedagem estática do frontend (SPA)
+- **Tecnologia**: React 19 + TanStack Router (file-based routing)
+- **Vantagens**:
+  - Baixa latência para conteúdo estático
+  - Custo-benefício para SPAs
+  - Sem necessidade de servidor para roteamento client-side
+- **Deploy**: GitHub Actions publica build otimizado
 
-### SES
-O Amazon Simple Email Service (SES) é empregado para o envio de e-mails transacionais e notificações, com suporte a autenticações SPF/DKIM e monitoramento de reputação.
+### SES (E-mail Transacional) - TODO
 
-## Azure
-A **Microsoft Azure** hospeda um segundo **cluster Docker Swarm** composto por **duas VMs**, proporcionando **redundância geográfica** e **continuidade de negócio**. A infraestrutura é **provisionada por Terraform**, cujo **estado** permanece em **Azure Blob Storage**, assegurando controle de mudanças e reprodutibilidade.
+- **Status**: Planejado, não implementado
+- **Propósito**: Envio de e-mails transacionais (confirmações de reserva, recuperação de senha)
+- **Recursos**: SPF/DKIM, monitoramento de reputação
 
-### VMs (Compute)
-As **máquinas virtuais** da Azure espelham a pilha de serviços executada na AWS (Database, Backend, Webpage, Traefik, Prometheus, Grafana, Metabase e Umami), elevando a resiliência do ambiente.
+## Azure (Infraestrutura Backup - Standby)
 
-### Blob Storage (estado do Terraform)
-O **Azure Blob Storage** armazena o **state** do **Terraform** de maneira centralizada e segura, evitando divergências de configuração entre execuções.
+**Status**: Parte da infraestrutura de backup multi-cloud (não utilizada em produção atual)
+
+A **Microsoft Azure** faz parte da solução de backup que proporciona **redundância geográfica** e **continuidade de negócio**. A infraestrutura é **provisionada por Terraform**, cujo **estado** permanece em **Azure Blob Storage**.
+
+### VMs (Compute - Backup)
+
+- **Status**: Standby (pronta para ativação)
+- **Provisionamento**: Terraform
+- **Orquestração**: Docker Swarm
+- **Serviços**: Espelha pilha completa (Database, Backend, Frontend, Traefik, Prometheus, Grafana, Metabase, Umami)
+- **Propósito**: Redundância geográfica, failover em caso de falha crítica AWS
+
+### Blob Storage (Estado Terraform)
+
+- **Propósito**: Armazenamento centralizado do state do Terraform
+- **Benefícios**: Controle de mudanças, reprodutibilidade, versionamento
+- **Integração**: Sincronizado com repositório de infraestrutura backup
 
 ## Backend
-**Repositório:** https://tools.ages.pucrs.br/pro-mata/backend
+
+**Repositório:** <https://tools.ages.pucrs.br/pro-mata/backend>
 
 ### Definições de linguagem e bibliotecas
 
@@ -69,7 +161,7 @@ O **Azure Blob Storage** armazena o **state** do **Terraform** de maneira centra
 - **ESLint / Prettier** — Lint e formatação padronizada.
 - **@umami/node** — Coleta de analytics de eventos de aplicação (módulo dedicado).
 
-### Módulos do Sistema
+### Módulos do Sistema (Backend)
 
 - **Analytics**  
   Responsável pela integração com o **Umami**. Inicializa o cliente de analytics, publica eventos (ex.: `trackHello`, `trackPasswordChange`) e evita execução em ambientes de **test/CI**. Parametrizado por `UMAMI_URL` e `UMAMI_WEBSITE_ID`.
@@ -92,7 +184,7 @@ O **Azure Blob Storage** armazena o **state** do **Terraform** de maneira centra
 
 ## Frontend
 
-**Repositório:** https://tools.ages.pucrs.br/pro-mata/frontend
+**Repositório:** <https://tools.ages.pucrs.br/pro-mata/frontend>
 
 ### Definições de Tecnologias e Bibliotecas
 
@@ -110,7 +202,7 @@ O **Azure Blob Storage** armazena o **state** do **Terraform** de maneira centra
 - **Vitest** — Testes unitários com `run`, `watch` e UI.
 - **Node.js / npm** — Toolchain e scripts de desenvolvimento.
 
-### Módulos do Sistema
+### Módulos do Sistema - Frontend
 
 - **App (Bootstrap)** — Inicialização do Router/QueryClient, importação de estilos globais e provisionamento de toasts (Sonner).
 - **Rotas (TanStack Router)** — Arquitetura file-based; rotas públicas em `/(index)` e seção administrativa em `/admin` com `beforeLoad` para verificação de permissões.