# Advisor Radar

O mesmo sinal, visto dos dois lados da conversa.

[HTML](https://leohteixeira.com/pt/projects/advisor-radar) · Leonardo Teixeira

## O produto

O Advisor Radar transforma eventos de conta e mensagens de clientes em trabalho priorizado para a assessoria financeira. Entre como cliente fictício para provocar sinais, ou como assessor para trabalhar a fila, revisar classificações incertas e acompanhar casos com SLA por segmento.

Stack: Go, React, TypeScript, PostgreSQL, RabbitMQ, Elasticsearch, gRPC, Jev, OpenTelemetry

### Alertas proativos

Regras determinísticas identificam saques, quedas de patrimônio, aportes grandes, mudanças de segmento, clientes sem contato e compras acima do perfil.

### Triagem de mensagens

Intenção, frustração, risco de saída e pedido humano. Confiança abaixo de 0,85 segue para revisão humana; falhas do modelo usam fallback heurístico marcado.

### Casos com SLA

Aberto, em atendimento, aguardando cliente, resolvido. SLAs por segmento escalam por TTL e dead-letter exchanges do RabbitMQ.

### Telas pelo servidor

O backend escolhe a variante de cada seção pelo momento do cliente. O frontend renderiza um catálogo fixo de componentes.

## O fluxo principal

1. **O cliente abre uma reclamação no app** — O app React envia HTTP/JSON versionado ao BFF, que valida e repassa o comando.

2. **O BFF entrega o comando ao account-sim** — O gRPC propaga deadline e contexto de tracing ao serviço de conta.

3. **Mensagem e evento gravados na mesma transação** — O PostgreSQL salva a mensagem e a outbox na mesma transação. Se o broker estiver indisponível, o evento continua disponível para entrega.

4. **O relay publica no RabbitMQ** — O evento contém event_id, occurred_at, customer_id e schema_version para correlação dos eventos. A propagação de contexto de trace pelo RabbitMQ ainda não está implementada.

5. **A triagem classifica a mensagem** — A inbox idempotente deduplica por event_id. O Jev classifica intenção, frustração, risco de saída e pedido humano. Um fallback heurístico marcado cobre a indisponibilidade do modelo; confiança abaixo de 0,85 segue para revisão humana.

6. **Uma regra gera o alerta e o caso ganha SLA** — Regras determinísticas do advisory geram alertas. O cases usa o segmento do cliente no SLA; TTL e dead-letter exchanges do RabbitMQ controlam o escalonamento.

7. **A visão 360 é atualizada** — O timeline-indexer grava eventos, mensagens classificadas e casos no Elasticsearch para a busca na visão 360 do cliente.

8. **O alerta aparece na fila do assessor** — O BFF consome alert.raised e envia a atualização por SSE, sem recarregar a página.

## Arquitetura

```text
React → HTTP/JSON → BFF → gRPC → account-sim → PostgreSQL + outbox
Relay da outbox → RabbitMQ → triage / advisory / cases / timeline-indexer
Jev → classificação tipada · Elasticsearch → timeline · BFF → SSE → React
```

### Seis serviços Go

account-sim, triage, advisory, cases, timeline-indexer e o BFF sem estado têm responsabilidades explícitas. Cada serviço com estado possui seu PostgreSQL; o RabbitMQ transporta eventos.

### Telas do cliente dirigidas pelo servidor

O BFF retorna um schema tipado de página, seções e componentes para o momento do cliente. O React renderiza um catálogo fixo. A apresentação incorporada mantém três abas de clientes, JSON ao vivo, regras dos componentes, rolagem e nova tentativa. A prévia do telefone é intencionalmente somente leitura.

## Disponibilidade e limites

Demonstração técnica com clientes, nomes, marcas e movimentações fictícios. Sem vínculo com instituição financeira real e sem envio de mensagens a clientes reais. A SDUI interativa requer JavaScript e BFF disponível; esta explicação não. Uma meta de latência não representa um resultado medido.

[Abrir demo](https://leohteixeira.com/advisor-radar/fila)

[Código no GitHub](https://github.com/leohteixeira/advisor-radar)