Arquitetura Pró-Mata - Infraestrutura e Banco de Dados

Modelagem do Banco de Dados

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.