Arquitetura do Sistema

3. Visao Geral da Arquitetura

O sistema segue a estrutura de modulos do ABP Framework, com separacao em camadas bem definidas, parcialmente violada em alguns projetos (detalhado na secao 4).

Camadas principais (visao resumida)

1. Clientes: PWA Angular/Ionic, app Android e app iOS.
2. Edge: Cloudflare + ingress Nginx/Traefik.
3. Backend: cargo-fleet-api e cargo-fleet-auth em AWS EKS.
4. Dados: Redis (pod K8s, sem persistencia) + PostgreSQL externo.
5. Integracoes: Galileu, Meta Graph API, CargaAdicional API, ScraperOrchestrator e Firebase FCM.

Pontos de atencao imediatos desta topologia

• Replicas unicas em producao para API e AuthServer.
• Redis com maxmemory 2MB e emptyDir, alto risco operacional.
• Dependencias externas criticas concentradas em workers de processamento.

Background Workers ativos na API (HttpApi.Host):

4. Mapa de Modulos e Dependencias

Grafo de dependencias entre projetos (.NET)

cargo_fleet.Domain.Shared
  (sem ProjectReference — correto)
  ^
  |
cargo_fleet.Domain
  -> Domain.Shared (correto)
  -> FirebaseAdmin 3.3.0 (VIOLACAO: infra no Domain)
  ^
  |
cargo_fleet.Application.Contracts
  -> Domain.Shared (correto)
  -> Domain (VIOLACAO: Contracts nao deveria referenciar Domain)
  ^
  |
cargo_fleet.Application
  -> Domain (correto)
  -> Application.Contracts (correto)
  -> Scryber.Core, MiniExcel, HttpClient, Polly (implementacoes no Application)
  ^
  |
cargo_fleet.EntityFrameworkCore
  -> Domain (correto)
  ^
  |
cargo_fleet.HttpApi
  -> Application.Contracts (correto)
  ^
  |
cargo_fleet.HttpApi.Host
  -> Application, EntityFrameworkCore, HttpApi
  -> Serilog, Redis, HealthChecks, FirebaseAdmin, Workers
  ^
cargo_fleet.AuthServer -> EntityFrameworkCore
cargo_fleet.DbMigrator -> EntityFrameworkCore + Application.Contracts
cargo_fleet.HttpApi.Client -> Application.Contracts

Modulos de dominio identificados

Violacoes de camada confirmadas

1. FirebaseAdmin no Domain (cargo_fleet.Domain.csproj linha 16): infraestrutura de push notification referenciada diretamente na camada de dominio.
2. Application.Contracts referencia Domain (cargo_fleet.Application.Contracts.csproj linha 13): contratos de aplicacao acoplados a entidades de dominio, violando o principio de que contratos devem depender apenas de Domain.Shared.
3. ServiceConfigurationContext injetado como dependencia runtime (CargaAdicionalService.cs linha 27): objeto de configuracao de modulo ABP injetado em servico de aplicacao, uso incorreto do ciclo de vida.

5. Fluxos Criticos do Sistema

5.1 Autenticacao e Login

[Angular] -> POST /connect/token (OpenIddict/AuthServer)
          <- access_token + refresh_token
[Angular] -> GET /api/abp/application-configuration (ABP)
          <- permissoes, configuracoes de tenant

O fluxo de autenticacao usa OAuth2 Authorization Code com PKCE no frontend (oAuthConfig em environment.prod.ts). O AuthServer (OpenIddict Pro) esta em replica unica com estrategia Recreate, sem rollback gracioso.

5.2 Ciclo de processamento de ofertas (Background)

ProcessarOfertasWorker (a cada ~5min por tenant, paralelo)
  -> GalileuApiService.AuthenticateAsync(login, senha_descriptografada)
  -> CriarOfertasJob: busca ofertas na API Galileu -> salva no PostgreSQL
  -> AceitarOfertasJob: avalia regras de aceite automatico
       -> OfertasAceitePreparationService: adquire lock Redis por oferta
       -> OfertasAceiteExecucaoAppService: confirma aceite na API Galileu
       -> NotificationDispatcher: envia FCM via Firebase

AtualizarOfertasWorker (continuo, sequencial por tenant)
  -> Busca ofertas em lotes de 200 na API Galileu
  -> Atualiza status no PostgreSQL
  -> WhatsAppMessageService: dispara mensagem na Graph API Meta

5.3 Cadastro e gestao de credenciais Galileu

[Frontend] -> POST /api/app/galileu-credentials
           -> GalileuCredentialsAppService.CreateAsync()
              -> GalileuApiService.AuthenticateAsync() (valida credenciais)
              -> PasswordEncryptionService.Encrypt(senha) (passphrase fraca)
              -> Salva GalileuCredential no banco
              -> Publica GalileuCredentialCreatedEto com login + senha em texto plano
                 -> CargaAdicionalScraperService.ConfigurarTenantAsync(login, senha_plana)

5.4 Registro de device token (push notifications)

[App Mobile] -> POST /api/app/device-token (SEM autenticacao)
             <- DeviceToken inserido diretamente via IRepository<DeviceToken>
[Backend]    -> FirebaseAdmin.SendMulticastAsync(tokens, payload)

5.5 Consulta de ofertas pelo usuario

[Frontend] -> GET /api/app/ofertas (com JWT Bearer)
           -> EfCoreOfertaRepository.GetListAsync()
              -> Subquery correlacionada O(n²) para deduplicacao por CodigoB100
           <- Lista paginada de ofertas

5.6 Exportacao PDF

[Frontend] -> GET /api/app/printing/... (endpoint com [AllowAnonymous])
           -> PrintingAppService.PrintAsyncApiStatus()
              -> Busca dados no banco (sem cancelation token)
              -> Scryber.Core: gera PDF sincrono em arquivo temporario
              -> File.ReadAllBytesAsync(tmpFile)
              <- byte[] PDF (arquivo temporario NAO e apagado)

5.7 Verificacao de cargas adicionais

ProcessarOfertasWorker -> CargaAdicionalService.VerificarCargasAdicionaisEmLoteAsync()
  -> GetAccessTokenAsync(): solicita token OAuth2 (password grant, sem cache)
  -> POST cargaadicional-api-prd/api/app/oferta-scraps/custom-batch
  <- Lista de OfertaScrapBatchResult

7. Riscos de Seguranca

Resumo consolidado por categoria

Exposicao de segredos no repositorio

Cinco classes distintas de segredos foram confirmadas no repositorio Git:

O .gitignore raiz nao inclui appsettings.json, environment.prod.ts, google-services.json, ou GoogleService-Info.plist. Somente firebase-credentials.json (service account) e os arquivos env.yml dos ambientes estao no .gitignore.

Controle de acesso

LGPD e privacidade

---

7.2 Achados de Seguranca — Segunda Passagem

Consulte a secao 6.2 para o detalhamento completo de cada achado SEC2-01 a SEC2-17. Tabela resumo:

Observacoes LGPD — Segunda Passagem:

• GalileuApiService.cs linha 136 loga o payload completo da resposta da API Galileu com LogDebug, que pode conter dados pessoais de motoristas e enderecos. Se o nivel de log em producao incluir Debug, ha violacao LGPD.
• OfertaCreateDto e OfertaDto incluem campos como Embarcador, CEP e enderecos que podem ser dados pessoais (nome da empresa ou pessoa fisica embarcadora).
• MetricasAppService usa [DisableAuditing] em operacao que acessa dados de todos os tenants — ausencia de trilha de auditoria para acesso cross-tenant.

Seguranca mobile — Segunda Passagem:

• Uso correto de @aparajita/capacitor-secure-storage para armazenar refresh token (iOS Keychain, Android EncryptedSharedPreferences) — ponto positivo confirmado.
• allowDeviceCredential: true em BiometricLoginService permite fallback para PIN/padrao do dispositivo, reduzindo garantia de "usuario presente" para "dispositivo desbloqueado".

8. Gargalos de Escalabilidade e Performance

8.1 Criticos (risco de indisponibilidade)

---

SCALE-C1 — Redis maxmemory 2MB em producao

• Tipo: achado confirmado
• Evidencia: .github/kubernetes/production/redis.yml linha 7 — maxmemory: 2mb
• Impacto tecnico: Com apenas 2 MB, o Redis sera incapaz de armazenar DataProtection keys, distributed locks e cache de sessao simultaneamente para multiplos tenants. Quando o limite e atingido, o Redis inicia eviction de chaves (politica padrao noeviction retorna erro, ou allkeys-lru remove chaves ativas). Perda de DataProtection keys causa logout em massa. Perda de locks causa condicoes de corrida.
• Recomendacao: Aumentar para pelo menos 256 MB como medida imediata. Migrar para AWS ElastiCache com replicacao como solucao definitiva.

---

SCALE-C2 — ProcessarOfertasWorker sem limite de concorrencia entre tenants

• Tipo: achado confirmado
• Evidencia: ProcessarOfertasWorker.cs linhas 57-71 — Task.WhenAll(tasks) onde tasks cresce linearmente com o numero de tenants. Timer.Period = 1 (milissegundo).
• Impacto tecnico: Com N tenants ativos, N threads simultaneas fazem requests para a API Galileu, abrem conexoes com o PostgreSQL e competem por locks Redis. Sem pool de threads limitado, o crescimento linear de tenants degrada exponencialmente a performance.
• Recomendacao: Implementar SemaphoreSlim com limite configuravel (ex: max 5 tenants simultaneos). Considerar usar Hangfire ou ABP Background Jobs com fila para controle de throughput.

---

8.2 Altos (degradacao progressiva)

---

SCALE-H1 — Subquery correlacionada O(n²) na deduplicacao de ofertas

• Tipo: achado confirmado
• Evidencia: aspnet-core/src/cargo_fleet.EntityFrameworkCore/Ofertas/EfCoreOfertaRepository.cs linhas 263-273
  csharpCopiar

  var deduplicatedQuery = baseQuery.Select(o => new {
      Oferta = o,
      MaxData = baseQuery.Where(x => x.CodigoB100 == o.CodigoB100).Max(x => x.Data)
  }).Where(x => x.Oferta.Data == x.MaxData).Select(x => x.Oferta);

  Esta e uma subquery correlacionada: para cada linha de baseQuery, executa uma segunda query com WHERE CodigoB100 = ?. Com EF Core, isso pode ou nao ser traduzido para uma subquery SQL eficiente dependendo da versao e do provider.
• Impacto tecnico: Se traduzido como N+1 no PostgreSQL, uma listagem de 1.000 ofertas gera 1.001 queries. Mesmo com traducao correta para LATERAL JOIN, a ausencia de indice em CodigoB100 torna a operacao custosa.
• Recomendacao: Verificar o SQL gerado via context.Database.Log ou pgaudit. Substituir pela clausula DISTINCT ON (CodigoB100) ORDER BY CodigoB100, Data DESC nativa do PostgreSQL, que e O(n log n) com indice.

---

SCALE-H2 — Tabela AppOfertas sem indices criticos

• Tipo: achado confirmado
• Evidencia: Migration 20250827133229_CargaAdicionalAndIndexes.cs — indices presentes: IsCargaAdicional, OrigemCidadeId, DestinoCidadeId, PontoTnfCidadeId. Indices ausentes: CogProgColeta, TryAceite, Status, CodigoB100, Data.
• Impacto tecnico: Queries de filtragem por status (WHERE Status = 'ACEITA'), por data de processamento, e por codigo de oferta fazem full table scan. Com volume crescente de ofertas por tenant, o tempo de resposta degrada linearmente.
• Recomendacao: Criar indices compostos baseados nos padroes de query mais frequentes: (TenantId, Status), (TenantId, CogProgColeta), (TenantId, CodigoB100, Data DESC), (TenantId, TryAceite, Status).

---

SCALE-H3 — Geracao de PDF sincrona com arquivo temporario nao limpo

• Tipo: achado confirmado
• Evidencia: aspnet-core/src/cargo_fleet.Application/Scryber/PrintingAppService.cs linhas 62-68
  csharpCopiar

  var targetFilename = System.IO.Path.Combine(tmpDir, name);
  doc.SaveAsPDF(targetFilename, FileMode.Create);
  return await File.ReadAllBytesAsync(targetFilename);
  // arquivo nunca e deletado

• Impacto tecnico: Cada geracao de PDF cria um arquivo temporario que nunca e removido. Em ambiente containerizado, o filesystem do container se enche progressivamente. A geracao e sincrona, bloqueando a thread da requisicao durante toda a renderizacao (CPU intensivo).
• Recomendacao: Usar File.Delete(targetFilename) em bloco finally. Preferir MemoryStream para evitar I/O em disco. Adicionar CancellationToken para respeitar timeout de requisicao.

---

SCALE-H4 — GetAccessTokenAsync sem cache (OAuth2 token por requisicao)

• Tipo: achado confirmado
• Evidencia: aspnet-core/src/cargo_fleet.Application/CargasAdicionais/CargaAdicionalService.cs linhas 255-286 — GetAccessTokenAsync solicita novo token a cada chamada sem nenhum mecanismo de cache.
• Impacto tecnico: Cada verificacao de carga adicional gera uma requisicao extra de autenticacao. Em lotes com centenas de ofertas, isso multiplica o numero de chamadas HTTP desnecessarias.
• Recomendacao: Implementar cache do access token com expiracao baseada no campo expires_in da resposta, usando IDistributedCache (Redis).

---

SCALE-H5 — Distributed lock adquirido por oferta dentro de Unit of Work

• Tipo: achado confirmado
• Evidencia: aspnet-core/src/cargo_fleet.Application/Ofertas/Aceite/OfertasAceitePreparationService.cs linhas 66-102 — lock Redis adquirido e liberado (await using var lockHandle) dentro do loop, antes do uow.CompleteAsync(). O lock e liberado antes do commit da transacao.
• Impacto tecnico: A janela de tempo entre a liberacao do lock e o commit do uow permite que outro worker adquira o lock e leia a oferta com o estado ainda nao comitado. Condicao de corrida potencial em deployments com multiplos replicas (atualmente 1 replica, mas e um risco latente).
• Recomendacao: Manter o lock ate apos o uow.CompleteAsync(). Avaliar se o lock por oferta e realmente necessario dado que o acesso e serializado por batchSize = 20.

---

SCALE-H6 — N+1 em MetricasAppService

• Tipo: achado confirmado
• Evidencia: aspnet-core/src/cargo_fleet.Application/Metricas/MetricasAppService.cs linhas 119-134 — iteracao sobre tenantList com await _tenantManager.IsActiveAsync(tenant) por tenant, gerando uma query de banco por tenant por chamada.
• Impacto tecnico: O dashboard de metricas gera N queries para N tenants ativos a cada carregamento.
• Recomendacao: Cachear o resultado de GetListAsync + IsActiveAsync por um intervalo curto (ex: 5 minutos) usando IDistributedCache.

---

8.3 Medios

8.4 Infraestrutura de producao

A estrategia Recreate garante downtime a cada deploy. O pipeline atual (kubectl rollout restart) nao implementa blue/green, canary, ou qualquer mecanismo de rollback automatico.

---

8.2 Gargalos — Segunda Passagem

Esta secao consolida os achados de performance e escalabilidade identificados na segunda passagem. Os achados com classificacao "Gargalo atual confirmado" ja impactam o sistema com 22 tenants. Os classificados como "Risco de crescimento" tornam-se criticos com 150 tenants.

N+1 e queries ineficientes

Concorrencia e locks

Background workers

Indices ausentes no banco

Frontend e Docker

9. Divida Tecnica

9.1 Violacoes de arquitetura

9.2 Codigo comentado e legado

9.3 Qualidade de engenharia

10. Riscos Operacionais e de Producao

10.1 Deploy e rollback

• Sem approval gate: O pipeline Production.yaml e acionado automaticamente por push em master. Um commit acidental em master dispara deploy de producao imediato.
• Estrategia Recreate: Todos os componentes usam type: Recreate, garantindo downtime a cada deploy. Para o AuthServer, isso significa logout de todos os usuarios ativos.
• Sem rollback automatico: O pipeline nao implementa health check pos-deploy nem rollback automatico em caso de falha. O rollback manual requer acesso ao cluster e conhecimento do SHA anterior.
• DbMigrator como Job Kubernetes: O migrador de banco roda como Job Kubernetes a cada deploy (dbmigrator.yml). Migrations mal testadas sao aplicadas diretamente em producao.
• Pipeline sem separacao de responsabilidades: Build, push, e deploy sao etapas do mesmo job, rodando no runner gemini (provavelmente o mesmo k3s de desenvolvimento — hipotese, nao confirmado).

10.2 Observabilidade

• Logging: Serilog configurado, mas sem confirmacao de destino centralizado (CloudWatch, Elasticsearch, Datadog). Nao encontrado Serilog.Sinks.* alem do AspNetCore sink nos manifests.
• Metricas: Sem evidencia de integracao com Prometheus/Grafana ou CloudWatch Metrics.
• Tracing distribuido: Sem evidencia de OpenTelemetry ou AWS X-Ray.
• Alertas: Sem evidencia de alertas configurados para falha de workers, erros de autenticacao Galileu, ou uso de Redis.
• Health checks: Implementados (CargaAdicionalApiHealthCheck, cargo_fleetDatabaseCheck), mas o endpoint /health-ui esta potencialmente exposto sem autenticacao.

10.3 Incident response

• Workers silenciosos: ProcessarOfertasWorker e AtualizarOfertasWorker capturam todas as excecoes com try/catch generico e apenas logam. Uma falha sistemica (ex: Redis indisponivel) resulta em loop silencioso de erros sem alarme.
• ApiStatus como proxy de saude: O sistema usa ApiStatusManager.CreateAsync para registrar status Online/Offline da API Galileu, o que e uma forma manual de health check que nao se integra com alertas Kubernetes.
• Nao ha runbook identificado: Nenhum arquivo de procedimentos operacionais encontrado no repositorio.

10.4 Seguranca operacional

• Secrets no ConfigMap: O configmap.yaml de producao nao contem secrets diretamente, mas o mecanismo de injecao de secrets (secretRef: cargofleet-secrets) depende de Kubernetes Secrets configurados manualmente fora do repositorio. Nao ha evidencia de rotacao automatica.
• ECR com imagens latest: Imagens tagueadas com latest permitem que kubectl rollout restart puxe uma versao diferente da que foi validada, se uma nova imagem latest foi pushada entre o build e o restart.
• Runner gemini: O pipeline de producao usa runs-on: gemini (runner auto-hospedado). Se este runner e o mesmo k3s de desenvolvimento, ha risco de contaminacao entre ambientes.