Banco-de-Dados.md

 | [Home](Home) | [**Escopo**](Escopo) | [Processo](Processo) | [Sprints](Sprints) | [Design](Design) | [Arquitetura](Arquitetura) | [Repositórios](Repositórios) | [Banco de Dados](Banco de Dados) |
 | :----------: | :-------------------------------: | :------------------: | :--------------: | :--------------------------: | :--------------------: | :------------------------: | :--------------: |
+
+# Arquitetura Pró-Mata - Infraestrutura e Banco de Dados
+
+## Modelagem do Banco de Dados
+![modelagem_bd](uploads/dbce6a9c8ec654f7ff7e072481075fa4/modelagem_bd.png)
+
+O diagrama pode ser visualizado em: https://dbdiagram.io/d/68a0cd5d1d75ee360add7565
+
+## Banco de Dados PostgreSQL
+
+**Desenvolvimento**: Um container PostgreSQL simples que roda localmente. O Prisma ORM gerencia as migrações automaticamente.
+
+**Produção**: PostgreSQL com replicação master-slave, backups automáticos criptografados, e monitoramento futuro com Grafana e PostgreSQL exporter.
+
+## Como os Repositórios se Conectam
+
+**Backend**: Precisa do PostgreSQL e se conecta via variáveis de ambiente do `.env`
+
+**Frontend**: Só conversa com o backend através da API, não toca no banco diretamente
+
+**Infrastructure**: O "maestro" que orquestra tudo:
+- **Terraform**: Cria a infraestrutura no Azure (VMs, redes, IPs)
+- **Ansible**: Configura as máquinas e instala Docker Swarm
+- **Docker Swarm**: Gerencia os containers em produção
+
+## Segredos com Ansible Vault
+
+É como um cofre digital. Cada ambiente tem uma senha em `.vault_pass` que desbloqueia os segredos criptografados. No CI/CD, os segredos ficam no GitHub Secrets e são usados temporariamente durante o deploy.
+
+## Fluxo de Deploy
+
+1. Terraform cria/atualiza infraestrutura
+2. Ansible pega os IPs criados e configura as máquinas
+3. Docker Swarm orquestra os containers
+4. CI/CD detecta mudanças na tag `latest` e redeploya automaticamente
+
+## Cloudflare
+
+Funciona como DNS + CDN + proteção. Só precisa apontar os nameservers do registro.br para o Cloudflare.
+
+**Benefícios**: SSL gratuito, proteção DDoS, aceleração, esconde IP real do servidor.
+
+## Estratégias PostgreSQL em Homologação
+
+### Arquitetura Master-Slave
+
+**Banco Principal (Master)**: Recebe todas as escritas de dados. Roda em uma máquina com label `database.primary = true` no Docker Swarm.
+
+**Réplicas (Slaves)**: Copiam dados do master automaticamente. Servem apenas consultas de leitura. Quantidade configurável por variável `postgres_replica_count`.
+
+**Sincronização**: A replicação é automática via streaming replication do PostgreSQL. Se o master falhar, uma réplica pode ser promovida manualmente.
+
+### PgBouncer - Pool de Conexões
+
+**Função**: Atua como um "porteiro" entre aplicações e banco, controlando quantas conexões simultâneas são permitidas.
+
+**Configuração em Homologação**:
+- **Pool Mode**: `transaction` (mais eficiente, compartilha conexões entre transações)
+- **Max Client Conn**: 200 conexões cliente simultâneas
+- **Pool Size**: 25 conexões reais ao banco por pool
+- **Replicas**: 2-3 instâncias PgBouncer para alta disponibilidade
+
+**Benefícios**: Evita sobrecarga do banco com muitas conexões, reutiliza conexões existentes, distribui carga entre múltiplas instâncias.
+
+## PostgreSQL Alta Disponibilidade
+
+### Tolerância a Falhas
+
+**Auto-Recovery**: Docker Swarm reinicia automaticamente containers PostgreSQL que falharem. Configuração `restart_policy` com 3 tentativas e delay de 10-15 segundos.
+
+**Replication Slots**: Garantem que o master preserve WAL (Write-Ahead Logs) necessários para réplicas, mesmo se a réplica ficar offline temporariamente.
+
+**Health Checks**: Verificações `pg_isready` a cada 30 segundos com 5 tentativas before declaring failure. Se um nó falhar, é automaticamente removido do load balancing.
+
+**WAL Archiving**: Logs de transações são arquivados automaticamente para recuperação point-in-time em caso de corrupção de dados.
+
+### Disponibilidade Contínua
+
+**Hot Standby**: Réplicas ficam ativas e podem servir consultas de leitura mesmo durante sincronização com o master.
+
+**Physical Replication Slots**: Impedem que o master descarte WAL logs que réplicas ainda precisam, evitando quebra de sincronização.
+
+**Streaming Replication**: Dados são replicados em tempo real via conexão TCP contínua, mantendo réplicas sempre atualizadas.
+
+**Placement Constraints**: Docker Swarm garante que master e réplicas rodem em nós físicos diferentes (`node.labels.database.primary` vs `node.labels.database.replica`).
+
+### Recuperação de Desastres
+
+**Base Backup Automático**: Script `pg_basebackup` cria cópias completas do banco que podem ser usadas para restaurar réplicas ou criar novos masters.
+
+**Point-in-Time Recovery**: Combinação de backups + WAL archives permite restaurar banco para qualquer momento específico no passado.
+
+**Replication Slot Cleanup**: Limpa automaticamente slots órfãos para evitar acúmulo de WAL logs que consomem espaço em disco.
+
+**Failover Manual**: Se master falhar, uma réplica pode ser promovida manualmente a master usando comandos `pg_promote()`.
+
+Esta arquitetura garante que o sistema suporte falhas de hardware, rede ou software com perda mínima de dados e downtime reduzido.
\ No newline at end of file