bruno.dev
ENESPT
Get in touch

Open to developer roles & projects

Bruno de Souza Borges

Software developer specialised in databases. I build and ship products — from a competitive gaming platform to tools a team uses every day.

2,500+
commits
7
services in production
1,200+
matches processed

BrasilMIX · engineering scale in production

  • Software developer
  • Database specialist
  • Full-stack: React · Python · Node
  • Partner at Bewnans
  • Programming degree — in progress
  • Galicia, Spain

// 01. about

How I work

01

Database specialist

Data modelling, migrations and consistency under load: row locking for the virtual economy and the match queue, Redis for queues, rankings and live state.

140
tables & models in production
95
migrations
370+
indexes & constraints

Across BrasilMIX (MySQL + Redis) and the field app (SQLite, Prisma).

02

End to end

I design, code, deploy and maintain what I build. Architecture, code review and keeping it running for real users are all part of the job.

03

Shipped, not just prototyped

Everything on this page runs in production for real users — on servers I run with Docker, with real numbers behind it.

// 02. projects

What I've built

BrasilMIX

Competitive CS2 platform for the Brazilian community in Europe, built with a small team.

  • Own game-server orchestrator
  • Discord Activity, web app and bot
  • Anti-cheat
  • Virtual currency economy
  • Automatic highlights
monthly active players
113
matches in a month
209

Real production figures (Oct 2026).

  • Python
  • FastAPI
  • MySQL
  • Redis
  • React
  • TypeScript
  • Go
  • C#
  • Discord SDK

Operations app for telecom field teams

Brings work orders, materials and evidence into one place and automates the technicians' administrative work.

  • Work orders, materials and evidence in one app
  • Administrative work automated
  • Used every day by the team
  • TypeScript
  • React
  • Node
  • Prisma
  • SQLite
  • Playwright
  • Docker

// 03. deep-dive

Inside BrasilMIX

It started in January 2026 as MixBot, a Discord bot I wrote on my own, and grew into a platform built with a small team. Each part below says what was mine.

2,500+
commits of mine
9+
months building in production
4
languages: Python, TypeScript, Go, C#
7
services working together

Match lifecycle

  1. 01Player/mix in Discord
  2. 02Discord ActivityReact · Discord SDK
  3. 03BackendFastAPI · MySQL · Redis
  4. 04OrchestratorGo control-plane
  5. 05Agent on VPSGo · starts CS2
  6. 06CS2 serverC# plugins

Every round is reported back to the backend by webhook → rankings, economy, anti-cheat and highlights update on their own.

Pythonco-built

Web backend

Discord login, queue and draft, rankings, virtual currency economy and the admin API. Main contributor.

FastAPI · MySQL · Redis

TypeScriptco-built

Discord Activity, site & admin console

The app players use inside Discord: queue, profile, skins, tournaments — plus the public site and the admin console.

React 19 · Vite · Tailwind · Discord SDK

Pythonmine

Discord bot — where it started

Began as MixBot, my standalone bot (528 of its 555 commits are mine): voice-channel queue, ELO, matches via RCON + MatchZy, smurf detection. Today /mix opens the whole platform.

discord.py

Gocontributed

Game-server orchestrator

Decides where each match runs and starts CS2 servers on demand across VPSs.

control-plane + agents

C#mine

Match plugins

MatchGuardian and a customised MatchZy: match rules, pauses and live events sent to the backend.

CounterStrikeSharp · MatchZy fork

Go · C#mine

MixAC anti-cheat

Client on the player’s PC, plugin on the server and an API that ties both to the match.

Go & .NET client · server plugin · Python API

Pythonmine

Automatic highlights

Reads the match demo, finds multi-kills, clutches and aces, records them through OBS and encodes the clips.

demoparser2 · OBS · ffmpeg

// 04. case-studies

Case studies

Three real production problems in BrasilMIX: what broke, why, what I changed and what changed afterwards.

01MySQL · SQLAlchemy · FastAPI · Redis

Connection pool exhausted

Problem
The whole API froze as a match started: 30–75 s requests, a 40-connection pool exhausted and MySQL idle, every connection in Sleep.
Root cause
Connections held in Python, not a slow database. The SSE stream kept 1 connection per client for as long as it stayed open, and every draft request opened a 2nd nested session: 10 players at once took the 1st and waited for a 2nd that never came.
Fix
SSE session closed before the stream starts, draft data cached in Redis, a single-flight lock on the orchestrator call. I audited the backend's 44 nested sessions: 3 critical, all fixed.
Result
Both leaks left the hot path, and "one connection per request, released before slow I/O" became a written backend rule.
02MySQL · idempotency · binlog

Ranking counted twice

Problem
After a VPS reboot, a community's ranking points nearly doubled: 16 extra ELO applications, 15 of them in the same boot.
Root cause
The recovery routine re-applied ELO for every finished match on each sweep. The idempotency guard (ranking_match_applied, unique per match + scope) only had rows for recent matches; older ones were added again. Confirmed in the MySQL binlog.
Fix
A "nothing pending" check before the ranking block, and a ranking rebuild from match history.
Result
50 matches reprocessed: 45 applied, 5 skipped (no winner), 0 failures. Every player's rating checked against 2000 + sum of deltas. The rebuild also exposed a calibration ceiling that was never applied, fixed in the same pass.
03FastAPI · React · nginx logs

89% CPU with no real load

Problem
Backend at 60–89% CPU with 22 req/s from only 19 clients; /health p50 at 55 ms and a slow draft.
Root cause
Not a capacity problem. A client-side condition treated any match as DXD mode and swapped the idle poll (1 req/20 s) for the heavy one (3 req/2.5 s): 24× more requests. On a day with zero DXD matches, that mode's endpoint got 41,283 calls. And one component duplicated the poller of the API's most-called endpoint.
Fix
Condition fixed, a single shared poller, a longer interval while the app is in the background. I ruled out adding workers: that would treat a bug as demand.
Result
CPU from 60–89% to 19–39%; /health p50 from 55 to 2 ms and p90 from 129 to 14 ms; requests per client during the draft from 2.26 to 1.19 per second.

// 05. skills

Stack I work with

Frontend

  • React
  • TypeScript
  • Vite
  • Tailwind CSS

Databases

  • MySQL
  • SQLite
  • Redis
  • SQLAlchemy
  • Alembic
  • Prisma

Backend

  • Python
  • FastAPI
  • Node
  • Go
  • C# / .NET

Infra & automation

  • Docker
  • Own VPS
  • Playwright
  • Discord SDK
  • ffmpeg

Only what runs in the projects above.

// 06. contact

Let’s build something together?

Hiring for a developer role, or have a project in mind? Email is the fastest way to reach me.

contato@brunoborges.dev