Por que construir isso sem cliente nenhum pedindo
Framework bom esconde a parte difícil. Você chama dbContext.SaveChanges() e nem pensa em como o
dado chega ao disco sem se perder numa queda de luz. Chama BackgroundService e nem pensa em como
uma fila decide o que roda primeiro. Isso é ótimo pra entregar rápido. É ruim se um dia o
framework não resolve o seu caso e ninguém no time entende o que tem por baixo dele.
Fiz o caminho inverso nos últimos dias: three sistemas em C# puro, sem ORM, sem fila gerenciada, sem parser pronto. Não é sobre reinventar roda pra usar em produção. É sobre entender a roda por dentro, pra saber exatamente onde ela quebra quando o seu projeto de verdade precisar.
Quero um sistema desse nível pro meu projetoNexusDB — o que acontece quando seu banco de dados trava
Todo sistema que guarda dado importante depende de uma pergunta que ninguém faz até dar problema: se a luz cair no meio de uma escrita, o dado sobrevive? O NexusDB é um motor de banco de dados key-value que constrói essa garantia do zero: write-ahead log com checksum, memória intermediária ordenada, arquivos imutáveis em disco com compaction automática. A mesma família de arquitetura por trás do RocksDB, que roda dentro de bancos usados por empresa grande.
Pra você, isso não vira "produto pronto pra usar". Vira alguém que, quando seu sistema trava sob carga ou perde dado numa falha, sabe exatamente onde procurar, porque já construiu a peça que falhou, não só usou ela.
26 testes automatizados, incluindo um que derruba o log no meio de uma escrita de propósito e prova que a recuperação não perde nem meio-aplica nada. Código no GitHub.
Orbital — a fila que decide o que roda primeiro no seu sistema
Todo sistema com WhatsApp, e-mail em massa ou processamento em background tem uma fila escondida em algum lugar. A pergunta que decide se ela aguenta: o que acontece quando ela enche? O Orbital responde isso com prioridade real (um job urgente nunca fica preso atrás de mil jobs de rotina), retry com espera crescente quando algo falha, e um jeito de desligar o sistema sem matar o job que já estava na metade.
É a peça que separa "automação que funciona na demonstração" de "automação que aguenta um mês de operação real com pico de tráfego".
18 testes automatizados, dois deles provando o desligamento gracioso: um job em andamento termina normal dentro do prazo, outro é cancelado à força quando o prazo estoura. Código no GitHub.
Lyra — entender como o código vira execução
Esse é o mais didático dos três, e o que mais separa quem programa de quem entende programação. Lyra é uma linguagem própria: você escreve código nela, e por baixo dos panos ele passa por lexer, parser, compilador e uma máquina virtual que executa instrução por instrução, o mesmo caminho que Python ou Java fazem por dentro, só que visível, sem caixa preta.
Não existe uso comercial direto pra isso. Existe o que ele ensina: quando alguém entende como uma linguagem decide o que é escopo de variável, como uma função lembra de onde foi chamada, onde exatamente um programa trava numa recursão infinita, esse alguém debuga qualquer sistema mais rápido, em qualquer linguagem.
37 testes automatizados, incluindo recursão (Fibonacci) e um teste que prova que recursão infinita vira um erro controlado, nunca um travamento cego. Código no GitHub.
O que isso muda pro seu projeto
Três coisas concretas, não abstratas:
- Diagnóstico mais rápido quando algo dá errado. Sistema lento, fila entupida, dado inconsistente: problema que exige entender o que tem por dentro do framework, não só ler a documentação dele.
- Decisão de arquitetura com base real. Saber quando vale usar fila gerenciada (SQS, RabbitMQ) versus construir uma simples, ou quando um banco relacional resolve versus quando precisa de outra estrutura, vem de ter construído os dois lados.
- Código que aguenta escala, não só a demonstração. Os três projetos têm teste automatizado cobrindo o caminho de falha, não só o caminho feliz. É o padrão que uso em projeto de cliente também.