ByteHeavy
ByteHeavy
Nossos projetos
Ainda estamos no início da divulgação de portfólios de clientes, então estes são exemplos do tipo de engenharia que fazemos — não afirmações sobre projetos específicos de clientes.

TypeScript, Postgres, Redis
Construído para uma comunidade de Discord de médio porte que precisava de um sistema de moeda interno sem as brechas e condições de corrida que afetam a maioria dos bots de economia 'rápidos'. Cada alteração de saldo é envolvida em uma transação serializável do banco de dados, para que duas negociações simultâneas não possam gastar as mesmas moedas duas vezes — uma classe de bug que já quebrou silenciosamente mais economias de Discord do que qualquer invasor externo. Ações administrativas sensíveis (edições de saldo, concessões de itens, banimentos) são registradas em uma trilha de auditoria imutável, para que disputas tenham um histórico documentado em vez de uma discussão de 'ele disse, ela disse'. Todo o sistema foi testado sob carga para suportar o pico de uso simultâneo — milhares de interações nos mesmos poucos minutos durante um evento da comunidade — sem nunca atingir os limites de taxa da própria API do Discord, porque a fila de requisições é limitada e agrupada do nosso lado antes de chegar aos servidores do Discord.
Java, Paper API — portable pattern
Uma camada de detecção baseada em comportamento originalmente construída para um servidor de Minecraft (Paper API), projetada para identificar padrões de movimento, mira e combate estatisticamente anômalos sem exigir que os jogadores instalem nenhum mod do lado do cliente — todo o motor roda no servidor, então não há nada para um desenvolvedor de cheats fazer engenharia reversa ou contornar no cliente. A restrição rígida era desempenho: a lógica de detecção roda dentro do próprio loop de tick do servidor, então cada verificação foi analisada e otimizada até o microssegundo para evitar qualquer atraso perceptível para os milhares de jogadores legítimos ao redor daquele que está sendo observado. O padrão subjacente — detecção estatística de anomalias rodando dentro de um loop apertado em tempo real — não é exclusivo do Minecraft; a mesma arquitetura se aplica à detecção de fraude em qualquer sistema ao vivo em que 'algo parece errado' precisa ser identificado em milissegundos, não revisado um dia depois em um arquivo de log.
Go, PostgreSQL RLS
Um backend que atende várias organizações de clientes separadas a partir de uma única implantação compartilhada, com o Row-Level Security do PostgreSQL aplicando o isolamento de dados na própria camada do banco de dados — não apenas no código da aplicação, que um futuro bug poderia contornar. Mesmo um servidor de aplicação totalmente comprometido ou mal configurado não consegue vazar os dados de um cliente para outro, porque o próprio banco de dados recusa a consulta antes mesmo de executá-la, independentemente do que o código da aplicação pediu. Construído em Go especificamente porque suas goroutines leves permitem que uma única implantação mantenha confortavelmente milhares de conexões simultâneas por cliente, sem a sobrecarga de memória que um modelo de thread por requisição teria na mesma escala.
Go, Redis
Um serviço de gateway posicionado à frente de um conjunto de APIs de backend, construído para absorver tráfego intenso e irregular sem nunca deixar um pico derrubar os serviços por trás dele. A limitação de taxa distribuída e o cache de respostas ficam no Redis, compartilhados entre todas as instâncias do gateway, de modo que o limite é aplicado de forma consistente independentemente de qual instância recebe a requisição. Foi projetado explicitamente em torno da degradação graciosa: um pico repentino de 10x no tráfego é limitado e enfileirado na borda, de modo que o backend enxerga uma curva suave e absorvível em vez de uma parede — a diferença entre uma resposta lenta e uma indisponibilidade total.
// Client work previews are demoed live, not shipped as
// downloadable source — ask us for a walkthrough.