/projects/pulse
← Todos os projetosPulse
Um sistema ao vivo, em tempo real, embutido em um portfólio.
Design & implementação

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.
- BrowserUm cliente React mantendo uma conexão SignalR aberta.
- APIResolve a localização aproximada do visitante, publica a visita e transmite a nova contagem de presença para todos.
- OutboxO evento é bufferizado e descarregado no mesmo save da escrita, então não pode ser publicado para algo que não commitou.
- WorkerDrena o outbox via RabbitMQ e acrescenta a visita à trilha de auditoria.
- 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.