GaiaEx AcademyGaiaEx Academy
Padrões de Design de Software para Sistemas de Negociação
DesenvolvedorProgramação12 min read

Padrões de Design de Software para Sistemas de Negociação

Event sourcing, CQRS e padrões arquiteturais usados por corretoras

Compartilhar Posts

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.

CQRS + event log (conceptual) Write side commands validate append events Event log immutable ordered Read side projections Caches / SQL API queries Readers can lag slightly; writers stay the source of truth in the log.
Comandos produzem fatos; os consumidores constroem visões materializadas para consultas rápidas.

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.

Circuit breaker states CLOSED calls pass failures OPEN fast-fail timeout HALF trial call Half-open probes decide whether to close again or reopen.
Dispara em rajadas de falha; entra em espera para recuperação; testa com uma única chamada antes do tráfego total.

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.