
Padrões de Design de Software para Sistemas de Negociação
Event sourcing, CQRS e padrões arquiteturais usados por corretoras
Por que os padrões importam em sistemas de negociação
Software financeiro falha de formas caras: ordens duplicadas, saldos inconsistentes, falhas parciais silenciosas. Padrões de design não são troféus — são respostas a modos de falha recorrentes: event sourcing para auditabilidade, CQRS para escalar leituras de forma diferente das escritas, circuit breakers para interromper falhas em cascata, e idempotência para que retries não gerem operações duplicadas.
Pub/Sub e acoplamento fraco
Motores de casamento de ordens, verificações de risco e publicadores de dados de mercado não deveriam se chamar diretamente uns aos outros em uma grande bola de lama. Um barramento de publish/subscribe permite que o motor de casamento emita execuções (fills) enquanto os serviços downstream se inscrevem sem conhecer os detalhes de implementação dos serviços upstream — mas você ainda precisa escolher as garantias de entrega (pelo menos uma vez vs exatamente uma vez) e a retenção para reprodução (replay).
Circuit breakers e bulkheads
Um circuit breaker para de chamar uma dependência doente depois de falhas repetidas, dando a ela tempo para se recuperar e protegendo seus pools de threads. Os bulkheads isolam pools de recursos para que um job de análise desgovernado não consiga esgotar o envio de ordens.
Máquinas de estado e idempotência
Ordens e transferências têm ciclos de vida bem definidos. Codifique as transições permitidas em uma máquina de estados finita para que saltos inválidos sejam impossíveis. Combine isso com chaves de idempotência nas requisições do cliente, para que retries de rede não consigam criar ordens duplicadas ao vivo.
Motores de casamento de ordens: prioridade preço-tempo
Praças centralizadas casam ordens que chegam com a liquidez em espera usando prioridade preço-tempo. Motores de casamento on-chain (como muitos designs de DEX em L1) precisam ser determinísticos: todo validador reexecuta a mesma sequência e chega a um estado idêntico — a GaiaEx herda esse modelo das regras da Hyperliquid.
Adoção pragmática
Não copie ciegamente todos os padrões no primeiro dia. Comece com fronteiras claras, logs estruturados e testes em torno da movimentação de dinheiro. Adicione um log de eventos quando a dor de reconciliação aparecer; adicione circuit breakers quando as APIs externas começarem a falhar. Padrões resolvem arranhões reais, não imaginários.