Argus
Dados de mercado explicáveis, estado reproduzível.
Execução offline em macOS x86_64 com Rust 1.95.0. A contagem agrega testes e doc-tests; não representa cobertura, throughput ou resultados de trading.
O problema: dados antes da decisão
O Argus investiga a fundação técnica de uma plataforma de análise de mercado: receber eventos, representar um livro de ofertas, preservar a origem dos dados e reproduzir o estado depois. A pergunta central é como confiar na sequência de dados antes de construir visualizações ou decisões sobre ela.
A implementação analisada se concentra nas fases iniciais da arquitetura. O projeto demonstra engenharia de dados de mercado e estruturas de baixo nível; a plataforma completa de trading continua sendo uma direção de evolução.
Workspace e fronteiras de responsabilidade
O workspace Rust separa tipos, tempo, precisão decimal, schemas, conectores, IPC, order book, armazenamento, replay, risco e observabilidade em crates. Os contratos compartilhados evitam que cada componente invente sua própria representação de preço ou evento.
A topologia planejada distingue Terminal, Data Plane, Risk Daemon e Research. Essa separação busca isolar falhas e credenciais. O código atual entrega componentes dessa fundação, e não quatro aplicações completas operando juntas.
Precisão e identidade dos eventos
Preço, quantidade e valores monetários têm unidades explícitas: ticks, lots e unidades monetárias mínimas, com representação inteira i128. Tick size e lot size participam do contrato. Isso reduz a mistura acidental entre unidades e o uso indiscriminado de ponto flutuante.
Os eventos canônicos carregam identificadores, venue, instrumento, sequência e timestamps de origem, recebimento e processamento. Separar esses tempos permite investigar onde ocorreu atraso, em vez de atribuir toda a latência à mesma etapa.
Pipeline e conectores determinísticos
O Data Plane une a interface de connector, eventos canônicos, livro de ofertas, acompanhamento de qualidade e publicação. O connector de fixtures produz entradas controladas para exercitar o pipeline sem depender de uma conexão real com uma exchange.
Snapshots substituem o estado do livro; deltas atualizam níveis e passam por checagens de sequência. Eventos de negociação e erros alimentam contadores. O pipeline inspecionado é síncrono; a migração para feeds assíncronos reais pertence às próximas etapas.
Livro de ofertas L2 e invariantes
O livro L2 mantém lados de compra e venda, melhores preços e níveis agregados. Sua implementação utiliza uma arena slab, com operações de snapshot, delta e estado de ressincronização. Sequências inválidas não devem ser confundidas com continuidade válida do mercado.
Os testes baseados em propriedades comparam a estrutura com uma implementação de referência e exercitam conjuntos de operações. O foco é equivalência de estado e invariantes do livro, não uma alegação de latência inferior sem benchmark medido.
SPSC, backpressure e limites da memória compartilhada
O ring SPSC possui um produtor e um consumidor, slots com sequência atômica e políticas explícitas de overflow. WaitProducer introduz backpressure; outras políticas permitem descartar eventos em canais onde isso é aceitável. Contadores registram descartes.
O componente analisado usa Arc e memória alocada no processo. É uma primitiva concorrente da fundação; seu nome SHM não comprova, sozinho, transporte por memória mapeada entre processos independentes. Essa distinção preserva o escopo real da implementação.
Armazenamento, checkpoints e replay
O armazenamento separa um tier em memória e um tier JSONL, com índice de segmentos e checkpoints. A sessão de replay lê eventos persistidos, controla um cursor temporal e oferece avanço e seek. Isso permite reconstruir sessões com entradas previamente registradas.
Branches guardam overlays de decisões e ordens simuladas sem duplicar toda a base de mercado. Uma verificação BLAKE3 compara a sequência serializada com um hash esperado. Replay determinístico é uma propriedade a verificar com fixtures e versões conhecidas, não garantia automática de qualquer feed externo.
Risco, auditoria e proveniência
O módulo de risco contém envelope e máquina de estados que distinguem condições operacionais e aceitação de intents. São contratos iniciais; validação completa de ordens e interação com venues ainda não estão comprovadas como um daemon operacional.
O log append-only encadeia entradas com hashes BLAKE3 e referências à entrada anterior. Proveniência e qualidade acompanham os dados. Esses mecanismos ajudam a investigar alterações e decisões, mas não substituem controles de acesso, retenção e revisão operacional.
Observabilidade e estratégia de verificação
O projeto inclui registry de métricas, exportador Prometheus, logs JSON e primitivas de tracing. O wrapper Sensitive organiza a representação de valores sensíveis em saídas de diagnóstico. Métricas de eventos, gaps e qualidade ajudam a entender o pipeline.
A suíte contém testes unitários, propriedades com Proptest e estruturas de benchmark com Criterion. A suíte local passou em 176 testes e doc-tests. A revisão não executou um benchmark de carga nem mediu throughput, disponibilidade ou resultados financeiros.
Competências demonstradas e evolução
O Argus conecta modelagem de domínio, precisão numérica, estruturas de dados, concorrência, persistência e reprodução de eventos. Minha formação em Economia e Ciência de Dados dá contexto às perguntas; Rust permite investigar seus contratos e invariantes.
Os próximos passos são integrar feeds reais, concluir as fronteiras entre processos e validar o caminho de risco. O repositório está público, com documentação e licença não comercial. A suíte local passou em 176 testes; não foram medidos resultados de trading.