SÃO PAULO, BR · DISPONÍVEL PARA VAGAS · BACKEND, WEB & IA

LeonardoSouza

Backend, Web & IA

CIÊNCIA DA COMPUTAÇÃO · INSPER · 5º SEMESTRE · SÃO PAULO

Construo backend, web e IA que rodam em produção: assistente LLM sobre os dados do próprio usuário, busca vetorial com pgvector para respostas ancoradas no contexto recuperado, outbox com retry exponencial e idempotência e front-end Next.js em sistema com usuário real. Three.js e GLSL entram quando o problema é de visualização — não antes.

curl -sO https://portfolio-souzxxxs-projects.vercel.app/leonardo-souza-cv.pdf
49k
partidas no pipeline de ML
218
arquivos de teste
12
módulos de domínio
4
serviços distribuídos
souzxxx

#02 · TRABALHO SELECIONADO

Projetos selecionados

Recorte do que sustenta uma conversa técnica: produto de IA em produção, busca vetorial com pgvector, e-commerce transacional com outbox e idempotência, e web com usuário real. Os links externos desta seção passam por verificação automática semanal.

FinanceHub — Dashboard — saldo, projeção e resumo da semana

Dashboard — saldo, projeção e resumo da semana · AMPLIAR

1 de 4

FinanceHub — Dashboard — saldo, projeção e resumo da semana

Dashboard — saldo, projeção e resumo da semana

BUILD 001 · ANO 2026 · REPO: PRIVADO

NO AR

FinanceHub

Plataforma financeira pessoal ponta a ponta com IA, em produção

Aplicação financeira com autenticação Supabase, dashboard de saldo/projeção, gestão de transações, orçamento por categoria, recorrências, importação/exportação e assistente IA conversacional (Luna). Monorepo Turbo com backend Python e frontend Next.js, deploy contínuo na Vercel. As capturas ao lado são da plataforma autenticada em produção.

  • 01Luna: contexto montado a partir das transações, categorias e orçamentos do próprio usuário autenticado, por consulta parametrizada filtrada por user_id
  • 02LLM via SDK da OpenAI apontado para a Groq (Llama 3.3 70B), teto de 500 tokens de saída e histórico truncado nas últimas 10 mensagens
  • 03Rate limit por rota com slowapi: 30 req/h no chat, 10/h nos insights, 5/h no relatório mensal
  • 04Row Level Security no Postgres nas tabelas do digest da Luna, sobre auth Supabase
  • 05Monorepo Turbo: API FastAPI + front Next.js, deploy contínuo na Vercel
DECISÃO 01

Por que Groq e não OpenAI direto?

O SDK é o mesmo; só muda a base_url. Llama 3.3 70B na Groq entrega latência muito menor por um custo que cabe num projeto pessoal, e a troca de provedor é uma linha de configuração se o trade-off mudar.

DECISÃO 02

Por que truncar o histórico em 10 mensagens?

O contexto financeiro do mês já ocupa o system prompt. Sem teto, uma conversa longa empurra o custo por request para cima e derruba a qualidade da resposta — 10 mensagens cobre a continuidade de um chat de finanças.

STACK: Next.js · TypeScript · Python · Turbo · Supabase · PostgreSQL · Groq · Llama 3.3 · Vercel

VER NO AR ↗

REPOSITÓRIO PRIVADO

Precificação QuintoAndar — Calculadora pública — 8 campos e preço estimado pela API

Calculadora pública — 8 campos e preço estimado pela API · AMPLIAR

1 de 4

Precificação QuintoAndar — Calculadora pública — 8 campos e preço estimado pela API

Calculadora pública — 8 campos e preço estimado pela API

BUILD 002 · ANO 2026 · REPO: PRIVADO

ENTREGUE

Precificação QuintoAndar

Preço de imóvel servido por API FastAPI na AWS: MAPE de 9,32% contra vendas reais de 2010, todo request logado e deploy contínuo com healthcheck

Sprint do 4º semestre do Insper com o QuintoAndar como parceiro: um time de quatro tinha que responder por quanto um imóvel vende e sustentar essa resposta em produção. O dataset é o Ames Housing — 1.285 imóveis residenciais de 2006 a 2009, 80 features — e o teste final foi contra 175 vendas reais de 2010, em holdout temporal com ids disjuntos dos do treino. Saíram dois modelos: uma regressão linear de 4 features para explicar preço a corretor e proprietário (MAPE 11,9%, R² 0,832) e um Gradient Boosting para a calculadora pública. Dos 52 commits do repositório da aplicação, 20 são meus — o maior volume do time: a API FastAPI, o logging de predições, os 36 testes, o script e o relatório de validação com os dados de 2010 e o modelo mínimo de 8 campos.

  • 01Gradient Boosting escolhido entre 5 modelos em validação cronológica: MAE de US$ 16.117 e MAPE de 9,83% no holdout de 2009, contra US$ 57.077 e 34,69% do baseline de mediana
  • 02Validação final contra as 175 vendas reais de 2010: MAE US$ 15.810, MAPE 9,32%, RMSE 26.071 e R² 0,894, com 92% dos imóveis dentro de 20% de erro
  • 03Calculadora pública reduzida de 12 para 8 campos por forward selection, no joelho da curva de erro
  • 04API FastAPI 0.115 com /predict, /predict/simples, /metrics e /health, contratos em Pydantic e o pré-processamento e as features portados do repo de modelo para ficarem idênticos aos do treino
  • 05Todo request gravado em SQLite — inclusive os 422 — com latência, versão do modelo, entrada e saída; o relatório de uso real fechou 300 chamadas com p95 de 11,7 ms e 94,3% de sucesso
  • 0636 testes em pytest distribuídos por 8 arquivos, e CI/CD que roda a suíte a cada push e, no merge da main, faz SSH + rsync e docker compose up --build --wait na EC2, com healthcheck depois do deploy
DECISÃO 01

Por que split cronológico e não aleatório?

Preço de imóvel anda com o tempo. Um split aleatório deixa venda de 2009 no treino e venda de 2007 no teste, e o modelo passa a ser avaliado sabendo o futuro. O corte é por data, a validação foi o ano de 2009, e o teste final foi contra as 175 vendas de 2010 — ano que o treino nunca viu, com ids disjuntos.

DECISÃO 02

Por que logar também os requests que falham com 422?

Log só de predição bem-sucedida mede o modelo, não o serviço. Gravar o 422 junto é o que mostra qual contrato o cliente está errando e com que frequência — é dele que sai a taxa de sucesso de 94,3% nas 300 chamadas do relatório de uso, em vez de uma impressão de que estava tudo bem.

DECISÃO 03

Por que não retreinar depois da validação com 2010?

O modelo treinado até 2009 errou 9,32% de MAPE num ano que nunca viu, contra 9,83% no holdout de 2009 — ou seja, não houve degradação a corrigir. Retreinar sem sinal de degradação troca um modelo medido por um modelo novo e não medido; a decisão de não mexer ficou escrita no relatório de validação.

STACK: Python · FastAPI · scikit-learn · Pydantic · SQLite · Docker · GitHub Actions · AWS EC2

REPOSITÓRIO PRIVADO

EC

Java 21

BUILD 003 · ANO 2026 · REPO: PRIVADO

EM CURSO

E-commerce transacional (sob NDA)

E-commerce transacional em Spring Boot: outbox com retry exponencial, idempotência de webhook e rate limit em Redis com circuit breaker

Loja própria de uma marca brasileira — nome sob contrato — em monolito modular Java 21 / Spring Boot 4.1 com storefront Next.js. O sistema move dinheiro, então a engenharia é quase toda sobre o caminho infeliz: webhook de pagamento validado por assinatura e deduplicado por tabela de webhooks processados; e-mails transacionais em outbox, com claim numa transação curta e envio fora de lock; retentativa com backoff exponencial e chave de idempotência no provedor; rate limit por chave em Redis via script Lua atômico que falha aberto quando o Redis cai. 12 módulos de domínio, migrações Flyway e testes de integração com Testcontainers em Postgres e Redis reais.

  • 01Outbox transacional: claim em transação curta, envio sem segurar lock, backoff exponencial de 30s dobrando até o teto de 1h com jitter
  • 02Idempotência ponta a ponta: webhook processado uma única vez, Idempotency-Key no provedor de e-mail
  • 03Rate limit por chave em Redis com script Lua atômico, que falha aberto e tem circuit breaker com sonda em half-open
  • 04Webhook de pagamento validado por assinatura HMAC; webhook de NF-e por token secreto próprio em comparação constant-time — ambos fail-closed
  • 0512 módulos de domínio, Flyway e testes de integração com Testcontainers (Postgres + Redis reais)
DECISÃO 01

Por que outbox e não chamar o provedor de e-mail dentro da transação?

Chamada HTTP dentro de transação segura conexão do pool enquanto espera a rede. O outbox quebra em três passos: transação curta que faz o claim, envio sem lock nenhum, transação curta que grava o resultado. A Idempotency-Key é o id da linha, então reenvio depois de crash é no-op.

DECISÃO 02

Por que o rate limiter falha ABERTO?

Se o Redis cair, bloquear todo o tráfego derruba o checkout — o custo de deixar passar tráfego por alguns minutos é menor que o de parar de vender. Ele loga ERROR para alertar, e o circuit breaker evita que cada request pague o timeout de conexão enquanto o Redis está fora.

DECISÃO 03

Por que monolito modular e não microsserviços?

Projeto solo, ~100 pedidos/mês. Microsserviço aqui compraria latência de rede e complexidade de deploy sem resolver nenhum problema que eu tenha. Os módulos têm fronteira clara para o dia em que valer a pena separar.

STACK: Java 21 · Spring Boot · PostgreSQL · Redis · Next.js · TypeScript · Testcontainers · Flyway · Docker

REPOSITÓRIO PRIVADO

PI

Next.js

BUILD 004 · ANO 2026 · REPO: PRIVADO

NO AR

Portal interno de construtora

Módulo de manual do proprietário num portal Next.js em produção: importação auditável de PDF, exportação em PDF/Excel e três otimizações de desempenho

Portal em Next.js 16 e React 19 que reúne sob um login só os sistemas internos de uma construtora — atendimento pós-obra, portal do cliente, avaliação de obras, departamento pessoal e o manual do proprietário do imóvel. É projeto de equipe em repositório privado: dos 583 commits, cerca de 150 são meus, e 108 deles estão concentrados no módulo do manual do proprietário — que é o que descrevo aqui. O documento que esse módulo gera é lido pelo comprador do imóvel como parte do contrato, então a exigência não é volume de tela: é que o dado de garantia esteja certo e que o caminho da correção seja auditável.

  • 01Módulo do manual do proprietário: de um manual real em PDF de 197 páginas sai um catálogo estruturado com 33 fichas de sistemas construtivos, 146 garantias, 39 manutenções preventivas, 78 cuidados e 131 casos de perda de garantia
  • 02O script de importação não escreve no banco: ele gera um .sql que um humano lê em diff antes de virar migração, e confere a extração por contagem estrutural em vez de conferir texto a olho
  • 03Três otimizações de desempenho minhas no mesmo módulo: fim do N+1 (uma consulta por obra em vez de uma por unidade), logo do PDF embutido uma vez em vez de por página, e lista de fichas carregada sem baixar o texto de todas
  • 04Sistema de equipe em produção: as 204 rotas de API passam por uma casca única que centraliza autenticação, papel, permissão de app e capacidade, relida do banco a cada request
  • 05A suíte roda contra um Postgres real e descartável, com as migrações de verdade e uma trava explícita para nunca apontar para o banco de produção — 181 arquivos de teste em Vitest e 6 suítes de ponta a ponta em Playwright
DECISÃO 01

Como importar dado de garantia de um PDF sem arriscar gravar uma extração errada num documento contratual?

O script de importação nunca grava no banco. Ele emite um .sql revisável em diff, que só vira migração depois de alguém ler; a conferência é estrutural (quantas fichas, quantas garantias, quantas preventivas), porque conferir centenas de linhas de texto a olho não é verificação, é esperança.

DECISÃO 02

Por que isto entra no portfólio como módulo, e não como produto inteiro?

É projeto de equipe: a maior parte dos commits do repositório é de outro desenvolvedor. O que reivindico é o que o histórico confirma como meu — o módulo do manual do proprietário e as otimizações dele. O resto do sistema aparece como contexto, não como autoria.

STACK: Next.js · React · TypeScript · Drizzle ORM · PostgreSQL · Tailwind · Vitest · Playwright · Vercel

REPOSITÓRIO PRIVADO

Sentinel — captura de tela

AMPLIAR

Sentinel — captura de tela

captura de tela

BUILD 005 · ANO 2026

NO AR

Sentinel

Monitoramento em tempo real: métricas do backend FastAPI transmitidas por WebSocket e renderizadas em 3D

Dashboard 3D full-stack em que os repositórios do meu GitHub orbitam um núcleo reativo como satélites. O tamanho do repositório mapeia stars + forks, a cor mapeia a linguagem e a velocidade da órbita mapeia o push mais recente. Shaders GLSL próprios desenham plasma, grids holográficos e camadas de glitch. O backend FastAPI transmite métricas de CPU, RAM e disco por WebSocket, e são elas que dirigem o pulso e a cor do núcleo.

  • 01Streaming de métricas por WebSocket com reconexão automática e limite de tentativas
  • 02Shaders GLSL próprios (plasma, grid holográfico, glitch)
  • 03Câmera fly-to com GSAP, bloom e aberração cromática
  • 04Backend FastAPI empurra métricas de CPU/RAM/disco que dirigem a cena

STACK: Next.js 16 · Three.js · React Three Fiber · GLSL · FastAPI · WebSocket · TypeScript · Docker

PW

Python

BUILD 006 · ANO 2026

EM CURSO

Project Wraeclast

Assistente com RAG: coleta diária em GitHub Actions, busca vetorial em Postgres com pgvector e resposta ancorada no contexto recuperado

Assistente pessoal para um jogo cuja meta muda a cada patch. Uma rotina diária coleta economia, o personagem do dono e conteúdo da comunidade, resume cada documento em JSON estruturado com um LLM e grava o embedding num Postgres com pgvector. Na pergunta, a API FastAPI embeda o texto, recupera os trechos mais próximos por distância de cosseno e monta um bloco de contexto com preços, ranking de farms e perfil do personagem — o LLM responde só sobre esse bloco. Não há modelo treinado nem fine-tuning: a inteligência é o corpus curado que cresce todo dia. O site em Next.js tem as telas de hoje, de farms e de bancada de craft, mais um grafo do conhecimento coletado.

  • 01Busca vetorial em Postgres com pgvector: embeddings de 1024 dimensões (truncagem Matryoshka para caber no índice HNSW) recuperados por distância de cosseno e filtráveis por tópico
  • 02Sem fine-tuning e sem modelo próprio: o contexto do chat é montado dos trechos recuperados mais preços, farms e perfil do personagem, e o prompt manda responder só com esse contexto e avisar quando o dado faltar
  • 03Coleta pesada separada da API: o cron diário roda no GitHub Actions, sem limite de tempo de execução; só as leituras e o /chat rodam como função serverless na Vercel
  • 04350 testes passando localmente com pytest e CI de ruff + pytest a cada push; a meta de 80% de cobertura por módulo está registrada e datada no ROADMAP
  • 05O /chat é fechado por token comparado em tempo constante com hmac.compare_digest, e falha fechado quando o token não está configurado
DECISÃO 01

Por que RAG e não fine-tuning?

O conteúdo muda a cada patch do jogo. Re-treinar modelo a cada mudança custa caro e envelhece rápido; um corpus curado que ganha documentos novos todo dia fica atualizado por construção, e o LLM entra só para curar texto em JSON e responder ancorado no que foi recuperado.

DECISÃO 02

Por que a coleta roda no GitHub Actions e não na própria API?

Função serverless tem teto de tempo de execução, e a coleta diária (scraping, embeddings e curadoria via LLM) não cabe nesse teto. O job de cron roda no Actions e só grava no banco; a API fica com leitura e chat, que são rápidos o bastante.

DECISÃO 03

Por que truncar o embedding para 1024 dimensões?

O provedor devolve 3072 dimensões por padrão e o índice HNSW do pgvector tem limite prático abaixo disso. A truncagem Matryoshka (parâmetro dimensions na própria chamada) faz o vetor caber no índice sem trocar de provedor nem perder a busca por similaridade.

STACK: Python · FastAPI · PostgreSQL · pgvector · Next.js · TypeScript · GitHub Actions · Vercel

#03 · ÍNDICE

Mais projetos

O que construí explorando linguagens, paradigmas e domínios — de Prolog a Python, de compilador a firmware embarcado, de jogos a automação de processos.

  1. #07STATUS: ENTREGUE

    Projeto Software — Microsserviços

    Sistema distribuído: Gateway (Java) + User Service (Python) + Connections (Java) + Frontend

    2026 · Java · Spring

  2. #08STATUS: ENTREGUE

    Gestão de núcleos CCA

    Spring Boot 4 / Java 21 + React 19 para núcleos socioeducativos: inscrição pública, matrícula, chamada e três papéis de acesso

    2025 · Java 21 · Spring Boot

  3. #09STATUS: ENTREGUE

    ML-Copa

    Predição de Copa do Mundo com XGBoost, Elo adaptativo e Dixon-Coles

    2026 · Python · XGBoost

  4. #10STATUS: EM CURSO

    CacaOS

    Firmware em C++ para ESP32 com tela touch: 8 mini-apps em LVGL e simulador SDL2 para desenvolver sem a placa

    2026 · C++ · PlatformIO

  5. #11STATUS: ENTREGUE

    Compilador de linguagem própria

    Compilador em Java: lexer, parser recursivo-descendente, interpretador tree-walking e gerador de assembly NASM x86 32-bit

    2026 · Java · Assembly x86

  6. #12STATUS: NO AR

    USP-Fono

    Parceria com a USP — aplicação web para fonoaudiologia

    2026 · JavaScript · React

  7. #13STATUS: ENTREGUE

    PredictFlow

    Frontend Next.js 15 de um painel de pipeline de vendas: importação de CSV, dashboards Chart.js e alerta de negociação atrasada

    2025 · Next.js 15 · React 19

  8. #14STATUS: ENTREGUE

    Universe

    Aplicação full-stack em Next.js e TypeScript

    2026 · Next.js · TypeScript

  9. #15STATUS: ENTREGUE

    Soli

    Aplicação social full-stack (JS + Python)

    2025 · JavaScript · Python

  10. #16STATUS: ENTREGUE

    Delivery Tracker

    Rastreamento de entregas em tempo real

    2025 · Python · JavaScript

  11. #17STATUS: ENTREGUE

    Pokédex

    Pokédex em React + TypeScript + Vite

    2026 · React · TypeScript

  12. #18STATUS: ENTREGUE

    RFQ Automation

    Automação de Request-For-Quote

    2024 · Python · Automation

  13. #19STATUS: ENTREGUE

    MD-Project

    Matemática Discreta em Prolog

    2026 · Prolog · Logic Programming

  14. #20STATUS: ENTREGUE

    Sistemas Hardware/Software

    Projetos de baixo nível e arquitetura de computadores

    2026 · C · Assembly

  15. #21STATUS: ENTREGUE

    Pokémon Showdown PS

    Sistema inspirado em Pokémon Showdown

    2026 · HTML · JavaScript

  16. #22STATUS: ENTREGUE

    Projeto Cálculo

    Cálculo resolvido e visualizado em Python

    2025 · Python · Math

#04 · FORMAÇÃO

Insper · BCC

Bacharelado em Ciência da Computação. Cinco semestres, da matemática discreta a sistemas distribuídos, IA aplicada, dados em larga escala e arquitetura de baixo nível.

S1

1º Semestre

Insper IntroFundamentos de programação e lógica
Aulas BaseMatemática, algoritmos e estruturas iniciais
SprintRede social em Django 5 + PostgreSQL com login Google; comentários, curtidas, denúncias e perfil
S2

2º Semestre

Bits e ProcessadoresArquitetura de computadores: ALU, datapath e linguagem de montagem
PhishingAppAplicação de segurança para detecção de phishing
Programação EficazPOO, padrões de projeto e qualidade de código
SprintPredictFlow: painel de pipeline de vendas em Next.js sobre API FastAPI/MongoDB; autenticação JWT e dashboards
S3

3º Semestre

ARQOBJArquitetura orientada a objetos avançada
Álgebra LinearFundamentos matemáticos para computação gráfica e ML
DiscretaMatemática discreta — implementação em Prolog (MD-Project)
Inteligência ArtificialQ-Learning, SARSA e agentes para NQueens, Frozen Lake e SPFC
SPRINTGestão de núcleos CCA em Spring Boot/Java 21 + React; módulos de inscrição e fila de espera
S4

4º Semestre

Projeto de SoftwareArquitetura de microsserviços com Docker (Java Gateway + Python User Service + JS Front)
Machine LearningModelagem supervisionada, validação e modelos em produção
Linguagens & ParadigmasEstudo formal de paradigmas além do imperativo e da orientação a objetos
Sistemas Hardware/SoftwareInterface com o sistema operacional, syscalls e programação de baixo nível
SprintPrecificação de imóveis com QuintoAndar: API FastAPI + Gradient Boosting em produção na AWS, CI/CD e 36 testes
S5

5º Semestre (atual)

Plataformas, Microsserviços e APIsDesign de APIs, comunicação entre serviços, plataformas escaláveis
Startup em Inteligência ArtificialProduto de IA do zero: validação, LLMs aplicados e entrada no mercado
MegadadosDados em larga escala: modelagem, pipelines e consultas distribuídas
Análise de Algoritmos e Entrevistas TécnicasComplexidade, estruturas de dados e resolução de problemas sob pressão
Jogos e InteraçãoLoops de jogo, interação em tempo real e experiência do usuário

#05 · FERRAMENTAL

Tecnologias que uso

Linguagens, front-end, back-end, ML e infra — do que eu escrevo até onde aquilo roda.

LINGUAGENS

TypeScript

Python

Java

JavaScript

Prolog

C

C++

FRONT-END

Next.js

React

Three.js

R3F

Tailwind

Framer Motion

GLSL Shaders

Vite

LVGL

BACK-END

Node.js

FastAPI

Spring

WebSocket

REST APIs

PostgreSQL

pgvector

Drizzle ORM

ML

XGBoost

Pandas

NumPy

Scikit-Learn

RAG

Embeddings

INFRA

Docker

Vercel

Turbo

GitHub Actions

Render

#06 · CONTATO · SÃO PAULO, BR · DESDE 2026

Vamos construir algo que se sustenta em produção.

Sou Leonardo Souza, estudante de Ciência da Computação no Insper (5º semestre), em São Paulo. Trabalho nas três frentes: backend, web e IA aplicada. No backend, fila outbox com retry exponencial e chave de idempotência, rate limit em Redis com circuit breaker que falha aberto e webhooks de pagamento validados por assinatura. Na web, front-end Next.js e TypeScript em sistema com usuário real — inclusive um módulo que gera um documento que o cliente final lê como parte do contrato. Em IA, assistente LLM sobre os dados do usuário autenticado e busca vetorial em Postgres com pgvector, onde a resposta é ancorada no que foi recuperado, sem fine-tuning. Prefiro medir a supor — e prefiro o sistema que se defende sozinho ao que só funciona no caminho feliz.