/projects/pulse

Todos os projetos

Pulse

Um sistema ao vivo, em tempo real, embutido em um portfólio.

Design & implementação

.NET 10SignalRRabbitMQRedisPostgresReact 19DockerTerraform
Captura de tela de Pulse

Visão geral

Um portfólio auto-hospedado que também funciona como demo de sistemas ao vivo: presença, visitas e métricas passam por um backend real orientado a eventos em tempo real, não dados simulados.

O que eu fiz

Projeto solo — o design, o backend orientado a eventos, o front-end e a infraestrutura em que roda.

  • O pipeline de presença em tempo real e seu mapa-múndi.
  • O outbox transacional e o backend orientado a eventos por trás dele.
  • O dashboard de operações público e as métricas que ele expõe.
  • O assistente de IA e o perfil que o fundamenta.
  • O deploy, do build do container à máquina onde ele roda.

O problema

Um currículo afirma senioridade e um repositório exige que alguém o leia; nenhum dos dois deixa um estranho ver um sistema funcionando. O Pulse fecha essa lacuna sendo ao mesmo tempo o portfólio e a coisa demonstrada. O que guiou sua construção não foi uma necessidade de usuário, e sim de evidência — tornar a afirmação conferível nos trinta segundos que alguém de fato gasta.

Arquitetura

Um backend .NET por trás de um cliente React. Uma conexão nova resolve a localização aproximada do visitante e publica um evento de visita por um outbox transacional, descarregado no mesmo save da escrita. Um worker drena esse outbox via RabbitMQ e acrescenta a trilha de auditoria no Postgres. O SignalR carrega a presença ao vivo — a contagem de conexões e as reações — enquanto o mapa-múndi lê as visitas acumuladas por polling, então o mapa desenha no próprio ritmo em vez de travar esperando esse round trip. O tracing passa por OpenTelemetry, e tudo sobe como containers atrás do Caddy.

  1. BrowserUm cliente React mantendo uma conexão SignalR aberta.
  2. APIResolve a localização aproximada do visitante, publica a visita e transmite a nova contagem de presença para todos.
  3. OutboxO evento é bufferizado e descarregado no mesmo save da escrita, então não pode ser publicado para algo que não commitou.
  4. WorkerDrena o outbox via RabbitMQ e acrescenta a visita à trilha de auditoria.
  5. World mapConsulta as visitas acumuladas no próprio ritmo, então o mapa nunca trava esperando o round trip que o alimenta.

O que faz

  • Presença ao vivo via SignalR — veja quem mais está no site agora, num mapa-múndi.
  • Backend .NET orientado a eventos com outbox transacional via RabbitMQ, Postgres e tracing com OpenTelemetry.
  • Um dashboard de operações público expondo métricas reais — conexões ao vivo, visitas ao longo do tempo e o feed de eventos conforme acontece.
  • Um assistente de IA baseado em um perfil mantido, respondendo em streaming sobre o autor.
  • Deploy com Docker Compose + Caddy sobre infraestrutura gerenciada com Terraform.

Decisões de engenharia

  • Um outbox transacional atrás de um contador de visitas

    Nada em contar visitas exige um. O ponto não é o contador — é que o padrão está aqui, ligado de ponta a ponta, em algo que o leitor pode ver funcionando em vez de um diagrama em que precisa acreditar. Num produto isso seria over-engineering; numa demonstração é a entrega.

  • Telemetria real, publicada

    O dashboard de operações expõe os números reais do sistema, o que significa que um leitor pode flagrar o site mentindo sobre si mesmo. A maioria dos portfólios faz afirmações que não dá para conferir; este escolheu a versão que dá.

  • Páginas pré-renderizadas em vez de app só no cliente

    O site renderiza seu conteúdo em HTML no build, então a primeira visita não espera JavaScript e um crawler vê a mesma página que uma pessoa — e, de quebra, um deploy pode ser verificado com uma única requisição em vez de um navegador.

  • Um assistente fundamentado num perfil mantido

    O assistente responde a partir de um arquivo que o autor mantém atualizado, e diz que não sabe em vez de inventar. Sem fundamento, ele seria a demonstração exatamente do oposto.