SaintMC
Desenvolvedor Líder & Arquiteto • 2019 - 2021
O Desafio
O SaintMC foi um projeto de infraestrutura de jogos distribuída full-stack que arquitetou e operou uma rede competitiva de Minecraft em produção, suportando os modos de jogo Hardcore Games (HG) e KitPvP. O sistema foi projetado para lidar com mais de 320 jogadores simultâneos com latência sub-50ms (p99), mantendo 97,4% de uptime apesar do gerenciamento de sessões de jogo stateful. A arquitetura demonstrou profunda expertise em engenharia de sistemas: validação autoritativa no servidor para prevenir trapaças no client-side, consistência de estado distribuída via transações Redis WATCH/MULTI/EXEC, ajuste fino de Garbage Collection da JVM (reduzindo tempos de pausa de 200-500ms para <50ms via otimização da 'young generation') e transações econômicas compatíveis com ACID prevenindo exploits de gasto duplo. A camada de proxy BungeeCord gerenciou o roteamento de conexões com afinidade de sessão (sticky session) para minimizar a latência. O PostgreSQL forneceu um estado econômico durável e consistente, enquanto o Redis serviu como um cache distribuído de alta performance.
Arquitetar consistência de estado em tempo real e justiça (fairness) para milhares de jogadores simultâneos. Restrições principais: (1) Prevenir condições de corrida (race conditions) quando jogadores interagem em mundos compartilhados através de múltiplos nós de servidor, (2) Manter latência de roundtrip (ping) abaixo de 100ms durante o jogo, (3) Manter tempos de pausa do Garbage Collection abaixo de 50ms para evitar quedas de TPS, (4) Prevenir exploits econômicos críticos para a receita via garantias de transação ACID, (5) Habilitar failover gracioso quando servidores de jogo caem sem desconectar os jogadores. O tradeoff fundamental: validação autoritativa do servidor elimina trapaças, mas aumenta a carga de CPU no backend.
Tech Stack
Destaques
- Consistência de Estado Distribuída
Arquitetura de servidor autoritativo eliminou trapaças no lado do cliente (client-side). Todo o estado do jogo (posição, inventário, vida) validado no lado do servidor antes da propagação. Prevenção de condições de corrida em transações concorrentes (kills simultâneos premiando itens) usando Redis WATCH/MULTI/EXEC para consistência transacional e row-level locking no PostgreSQL para durabilidade final.
- Otimização de GC da JVM
Redução dos tempos de pausa do Garbage Collection de 200-500ms para <50ms com 320 jogadores simultâneos. Tuning de G1GC → ZGC aumentando a proporção da 'young generation' de 5% para 40%, forçando objetos de vida curta a serem coletados cedo e reduzindo promoções para a 'old-gen'. Resultado: estabilidade da taxa de ticks melhorada de 18,5-20,0 TPS para 19,8-20,0 TPS, eliminando picos de lag perceptíveis.
- Estratégia de Cache em Camadas
Arquitetura de cache em 3 níveis: L1 objetos Spigot em memória, L2 cache distribuído Redis (TTL de 15min, 84% de taxa de acerto/hit ratio, latência <2ms), L3 fonte autoritativa PostgreSQL. Invalidação de cache via eventos pub/sub. Busca de sessão: <2ms (Redis) vs 20-50ms (PostgreSQL), reduzindo a carga do banco de dados em ~40%.
- Sistema Econômico ACID
Economia in-game crítica para a receita suportando 150-300 transações/segundo durante picos. Implementação de bloqueio otimista (optimistic locking) com lógica de retry para prevenir gasto duplo. Restrições ACID do PostgreSQL garantem: saldo nunca fica negativo, compras concorrentes não competem, todas as transações auditadas para detecção de fraude e resolução de disputas.
- Arquitetura de Escala Horizontal
Escalabilidade multi-camada: Proxies BungeeCord (150-200 jogadores cada, balanceamento de carga DNS round-robin), nós de servidor de jogo, PostgreSQL (réplicas de leitura para analytics). Capacidade total limitada pela contagem de servidores de jogo, não por limites arquiteturais.
- Operações de Produção & Monitoramento
Containerização Docker em instâncias GCP. Liveness probes do Kubernetes detectam servidores mortos e reiniciam pods automaticamente. CI/CD via GitHub Actions com deploys blue-green (atualizações com zero downtime). 97,4% de uptime durante o período operacional.
Galeria
