A Arquitectura Técnica por Trás de Exercícios Interactivos

Quando decidimos construir exercícios de código interactivos para a Star B, a primeira questão não foi de produto — foi de arquitectura. Como executar código arbitrário enviado por utilizadores de forma segura, rápida e com feedback preciso, tudo dentro do ciclo de uma resposta HTTP?

A resposta que encontrámos envolveu repensar cada camada do sistema: da infra ao UX, do modelo de segurança à forma como comunicamos erros. Este artigo documenta esse percurso.

📝

Submissão do utilizador

›

🔐

Validação & fila

›

📦

Container efémero

›

⚙️

Execução isolada

›

📊

Análise de output

›

💬

Feedback ao utilizador

O desafio do sandboxing

Executar código enviado por utilizadores é, por natureza, um problema de segurança. As abordagens mais comuns — interpretar o código no servidor diretamente, ou usar uma VM partilhada — criam riscos inaceitáveis: escalonamento de privilégios, acesso ao sistema de ficheiros, loops infinitos que consomem recursos do servidor.

A nossa abordagem combina isolamento a nível de sistema operativo com limites rigorosos por execução:

Cada submissão corre num container efémero criado em tempo de execução e destruído após a avaliação.
O acesso de rede é completamente desactivado dentro do container — nenhum socket pode ser aberto.
O tempo máximo de execução é de 10s, configurável por exercício.
Os limites de memória e CPU são impostos ao nível do cgroup, não apenas ao nível do processo.

Porquê containers efémeros e não pools? Pools de containers reutilizados são mais rápidos para arrancar, mas criam estado entre execuções — ficheiros temporários, variáveis de ambiente, memória não limpa. Preferimos a previsibilidade do isolamento total, mesmo ao custo de alguns milissegundos de startup.

<300ms tempo médio de resposta

10s timeout máximo por execução

3 linguagens suportadas no beta

Feedback que vai além de "certo ou errado"

A maioria dos sistemas de avaliação automática compara o output com uma string esperada. Se coincide, passa. Se não coincide, falha. Isso é insuficiente para ensino técnico sério.

O motor da Star B analisa o output em múltiplas dimensões:

Correcção funcional

Os casos de teste são definidos pelo autor do módulo, não por regex. Cada exercício tem um conjunto de inputs e outputs esperados que cobrem casos extremos — não apenas o caso feliz.

Qualidade da solução

Se a solução está correcta mas a complexidade temporal é sub-óptima, o sistema assinala isso. Um algoritmo O(n²) que passa em todos os testes mas podia ser O(n log n) não é uma solução completa.

Mensagens de erro contextuais

Em vez de devolver o stack trace bruto, o motor processa o erro e devolve uma mensagem adaptada ao contexto do exercício. "A tua função retorna None quando o input é uma lista vazia" é mais útil do que "TypeError: 'NoneType' object is not subscriptable".

exemplo de resposta do avaliador

      {
        "status": "partial",
        "passed": 7,
        "total": 10,
        "feedback": "A função falha quando o input contém valores negativos.",
        "hint": "Verifica a condição de paragem no teu loop.",
        "complexity": { "time": "O(n²)", "note": "Pode ser O(n log n)." }
      }
    

Suporte multi-linguagem

Actualmente suportamos Python 3.12, Node.js 22 e Rust 1.78. A arquitectura foi desenhada para que adicionar uma nova linguagem seja uma operação de configuração, não de engenharia:

Cada linguagem é definida por um runner Docker com o ambiente base.
Os limites de recursos (memória, CPU, timeout) são configurados por linguagem — Rust pode ter limites diferentes de Python.
O resto do pipeline — fila, análise de output, comunicação de feedback — é completamente agnóstico à linguagem.

Estamos a explorar suporte a Julia para os módulos de ciência computacional e C++ para os de sistemas embebidos. O modelo de segurança é o mesmo — apenas o runner muda.

O esquema por trás dos artigos

Para além do motor de avaliação, a plataforma tem um sistema de conteúdo construído sobre Drizzle ORM com PostgreSQL. O esquema de artigos foi desenhado com um princípio de privacidade em mente: rastrear o suficiente para melhorar o conteúdo, mas nunca associar visualizações a utilizadores identificáveis.

O campo visitorHash na tabela article_views é um hash de curta duração — não é persistente, não é reversível, e não está ligado a nenhum perfil de utilizador. Saber que um artigo foi lido 340 vezes é suficiente para tomar decisões de conteúdo. Não precisamos de saber por quem.

A flag isPreLaunch nos artigos activa comportamentos específicos — como o CTA que vês no final desta página — sem exigir lógica condicional espalhada pelo código de rendering. É uma decisão de esquema que simplifica o código de produto.

Etiquetas

engenharia sandboxing drizzle-orm arquitectura avaliação de código

⭐

Junte-se ao pré-lançamento

A Star B está a ser construída para engenheiros exigentes. Entre na lista de espera e tenha acesso antecipado à plataforma.

Entrar na lista de espera

A Arquitectura Técnica por Trás de Exercícios Interactivos em Tempo Real