Bruno de Souza Borges — Desenvolvedor de Software e Especialista em Banco de Dados

// 01. sobre

Como eu trabalho

01

Especialista em banco de dados

Modelagem de dados, migrations e consistência sob carga: row locking para a economia virtual e a fila de partidas, Redis para filas, rankings e estado em tempo real.

140
tabelas e models em produção: 95
migrations: 370+
índices e constraints

Somando BrasilMIX (MySQL + Redis) e o app de campo (SQLite, Prisma).

02

Ponta a ponta

Desenho, programo, faço deploy e mantenho o que construo. Arquitetura, code review e manter tudo rodando para usuários reais fazem parte do trabalho.

03

Em produção, não só protótipo

Tudo nesta página roda em produção para usuários reais — em servidores que administro com Docker, com números reais por trás.

// 02. projetos

O que já construí

BrasilMIX

Plataforma competitiva de CS2 para a comunidade brasileira na Europa, construída com um time enxuto.

Orquestrador próprio de servidores de jogo
Discord Activity, web app e bot
Anti-cheat próprio
Economia de moeda virtual
Highlights automáticos

jogadores ativos no mês: 113
partidas em um mês: 209

Números reais em produção (out 2026).

Python
FastAPI
MySQL
Redis
React
TypeScript
Go
C#
Discord SDK

Web app do BrasilMIX: painel da temporada, patente e lances da semana

App operacional para equipes de campo de telecom

Reúne ordens de serviço, materiais e evidências em um só lugar e automatiza o trabalho administrativo dos técnicos.

Ordens de serviço, materiais e evidências em um único app
Trabalho administrativo automatizado
Usado todos os dias pela equipe

TypeScript
React
Node
Prisma
SQLite
Playwright
Docker

No ar: webapp.bewnans.com · exige login

// 03. por-dentro

BrasilMIX por dentro

Começou em janeiro de 2026 como MixBot, um bot de Discord que escrevi sozinho, e cresceu até virar uma plataforma feita com um time pequeno. Cada bloco abaixo mostra o que foi meu.

2.500+
commits meus: 9+
meses construindo em produção: 4
linguagens: Python, TypeScript, Go, C#: 7
serviços rodando juntos

Ciclo de uma partida

01Jogador/mix no Discord
02Discord ActivityReact · Discord SDK
03BackendFastAPI · MySQL · Redis
04Orquestradorcontrol-plane em Go
05Agente na VPSGo · sobe o CS2
06Servidor CS2plugins em C#

Cada round volta ao backend por webhook → rankings, economia, anti-cheat e highlights atualizam sozinhos.

Pythonem equipe

Backend web

Login com Discord, fila e draft, rankings, economia de moeda virtual e API administrativa. Principal contribuidor.

FastAPI · MySQL · Redis

TypeScriptem equipe

Discord Activity, site e painel admin

O app que os jogadores usam dentro do Discord: fila, perfil, skins, torneios — além do site público e do painel administrativo.

React 19 · Vite · Tailwind · Discord SDK

Pythonmeu

Bot do Discord — onde tudo começou

Nasceu como MixBot, meu bot independente (528 dos 555 commits são meus): fila por canal de voz, ELO, partidas via RCON + MatchZy e detecção de smurf. Hoje o /mix abre toda a plataforma.

discord.py

Gocontribuí

Orquestrador de servidores

Decide onde cada partida roda e sobe servidores de CS2 sob demanda em várias VPSs.

control-plane + agentes

C#meu

Plugins de partida

MatchGuardian e um MatchZy customizado: regras de partida, pauses e eventos ao vivo enviados ao backend.

CounterStrikeSharp · fork do MatchZy

Go · C#meu

Anti-cheat MixAC

Cliente no PC do jogador, plugin no servidor e uma API que amarra os dois à partida.

cliente Go e .NET · plugin no servidor · API Python

Pythonmeu

Highlights automáticos

Lê a demo da partida, encontra multi-kills, clutches e aces, grava via OBS e codifica os clipes.

demoparser2 · OBS · ffmpeg

// 04. casos

Estudos de caso

Três problemas reais de produção no BrasilMIX: o que quebrou, por quê, o que mudei e o que mudou depois.

01MySQL · SQLAlchemy · FastAPI · Redis

Pool de conexões esgotado

Problema: API inteira travada no início de uma partida: requests de 30 a 75 s, pool de 40 conexões esgotado e o MySQL ocioso, todas as conexões em Sleep.
Causa raiz: Conexões presas no Python, não banco lento. O stream SSE segurava 1 conexão por cliente enquanto ficava aberto, e cada request do draft abria uma 2ª sessão aninhada: 10 jogadores ao mesmo tempo pegavam a 1ª e esperavam a 2ª, que nunca vinha.
Solução: Sessão do SSE fechada antes do stream, dados do draft em cache Redis, lock single-flight na chamada ao orquestrador. Auditei as 44 sessões aninhadas do backend: 3 críticas, todas corrigidas.
Resultado: Os dois vazamentos saíram do caminho quente, e "uma conexão por request, liberada antes de I/O lento" virou regra escrita do backend.

02MySQL · idempotência · binlog

Ranking somado duas vezes

Problema: Depois de um reboot da VPS, os pontos do ranking de uma comunidade quase dobraram: 16 aplicações de ELO a mais, 15 delas no mesmo boot.
Causa raiz: A rotina de recuperação reaplicava o ELO de toda partida encerrada a cada varredura. A trava de idempotência (ranking_match_applied, única por partida + escopo) só tinha registro das partidas mais recentes; as antigas foram somadas de novo. Confirmado no binlog do MySQL.
Solução: Checagem de "nada pendente" antes do bloco de ranking e rebuild do ranking a partir do histórico de partidas.
Resultado: 50 partidas reprocessadas: 45 aplicadas, 5 puladas (sem vencedor), 0 falhas. Rating de cada jogador conferido contra 2000 + soma dos deltas. O rebuild ainda expôs um teto de calibração que nunca era aplicado, corrigido junto.

03FastAPI · React · logs do nginx

89% de CPU sem carga real

Problema: Backend a 60–89% de CPU com 22 req/s vindos de só 19 clientes; /health com p50 de 55 ms e o draft lento.
Causa raiz: Não era falta de capacidade. Uma condição no cliente tratava qualquer partida como modo DXD e trocava o poll ocioso (1 req/20 s) pelo pesado (3 req/2,5 s): 24× mais requests. Num dia sem nenhuma partida DXD, o endpoint do modo recebeu 41.283 chamadas. E um componente duplicava o poller do endpoint mais chamado da API.
Solução: Condição corrigida, um único poller compartilhado, intervalo maior com o app em segundo plano. Descartei escalar workers: seria tratar bug como demanda.
Resultado: CPU de 60–89% para 19–39%; /health p50 de 55 para 2 ms e p90 de 129 para 14 ms; requests por cliente no draft de 2,26 para 1,19 por segundo.

// 05. skills

Stack com que trabalho

Frontend

React
TypeScript
Vite
Tailwind CSS

Banco de dados

MySQL
SQLite
Redis
SQLAlchemy
Alembic
Prisma

Backend

Python
FastAPI
Node
Go
C# / .NET

Infra e automação

Docker
VPS própria
Playwright
Discord SDK
ffmpeg

Apenas o que roda de verdade nos projetos acima.

// 06. contato

Vamos construir algo juntos?

Contratando para uma vaga de dev ou tem um projeto em mente? O email é o jeito mais rápido de falar comigo.

contato@brunoborges.dev