Arquitetura e comunicação

A aplicação de produção roda em Kubernetes. Os manifests ficam em deploy/kubernetes, com bases reutilizáveis e overlays por ambiente. Docker Compose permanece disponível para desenvolvimento e procedimentos locais; não é o fluxo normal de deploy da produção atual.

flowchart TD
    U[Web, Meta e callbacks WooCommerce] --> E[Entrada pública e Ingress]
    E --> G[flow-gateway]
    G --> W[whatsapp-entrypoint]
    G --> P[Painel e landing]
    G --> F[frontend-entrypoint]
    G --> C[woocommerce-wrapper e callbacks B2C]
    W --> B[Agentes B2B e B2C]
    F --> B
    F --> M[marketing-campaigns]
    B --> A[genai-wrapper]
    B --> C
    C --> WC[WooCommerce da loja]
    A --> IA[OpenAI, Gemini ou Claude]
    A --> V[Weaviate]
    B --> R[Redis]
    F --> D[PostgreSQL]
    C --> S[MinIO]

O diagrama mostra caminhos principais, não todos os acessos a persistência.

Entrada pública

O Ingress direciona o domínio da aplicação para flow-gateway. O gateway distribui rotas entre landing, painel, backend e callbacks. Os bancos e as APIs internas não devem ser expostos apenas para facilitar testes.

Os callbacks da Meta e os callbacks de produtos/pedidos têm destinos específicos. Uma aplicação que permite login ainda pode ter um webhook configurado no domínio antigo; valide cada integração separadamente.

Comunicação interna

Os serviços usam HTTP e DNS do Kubernetes, com nomes como frontend-entrypoint, genai-wrapper e woocommerce-wrapper. Um nome curto é resolvido no namespace do pod. Um endereço explicitamente apontado para outro namespace pode atravessar essa separação se houver rede e autorização disponíveis.

Os contratos compartilhados ficam em contracts/, os clientes comuns em packages/ e os serviços em modules/. Antes de alterar uma interface, verifique consumidores, autenticação e compatibilidade durante o rollout.

Processamento e disponibilidade

O conversation-outcome-worker executa trabalho de consolidação em segundo plano. Outros serviços também podem executar tarefas internas; desligar apenas o worker não garante que todo processamento automático esteja suspenso.

Readiness e liveness têm finalidades distintas. O sucesso do rollout e do /health é uma evidência inicial; concluir onboarding, conversar, buscar produtos e criar pedidos de teste exige validação funcional.

Consulte serviços, dados e configuração e CI/CD.