The Same Matching Engine Measured 130,000/s and 106/s
Matching engine throughput measured at four boundaries of one exchange, from 130,000/s to 106/s, with the conductor and outbox internals that explain the gap.
Matching EnginePerformanceThroughput
Engineering write-ups
Fourteen long-form articles on systems I built, rebuilt, or curate: a cryptocurrency exchange matching engine, a durable workflow engine in Rust, a Postgres scheduler, an OPAQUE implementation, a lattice sieving tool, and the zero-knowledge proof landscape. Each one names the components, walks a request through the real code, and reports the measurements, including the ones that went the wrong way.
RSS feed · By Oleksii Vasylenko, Technical Lead
Matching engines and exchange infrastructure
Five posts from rebuilding the matching path of a cryptocurrency exchange: the requirements we should have written first, the distributed lock we deleted, the Redis and Valkey cell design, the order book encoding, and a benchmark of the same engine at four boundaries that came out between 130,000 and 106 operations per second.
Matching engine architecture guide →
We Deleted the Distributed Lock From Our Matching Engine
Why a matching engine keeps one writer per market: the Redis lock bug that put two writers on one book, and the RabbitMQ queue setting that replaced it.
Matching EngineConcurrencyDistributed Locks
Distributed Matching Engine Architecture with Redis and Valkey
How a distributed matching engine on Redis or Valkey is built: one writer per market, hash-tagged atomic commits, WAITAOF durability, and a two-cell benchmark.
Matching EngineRedisValkey
Order Book Data Structures: Price-Time Priority in One Sorted Set
Order book data structures in a production matching engine: one Redis sorted set for price-time priority, O(1) cancellation, and a reconcile check for drift.
Matching EngineOrder BookData Structures
Cryptocurrency Exchange Requirements: The Spec I Wish We Had Written First
Cryptocurrency exchange system requirements for trading rules, consistency, ledger, throughput, recovery, and audit, each tied to the Bitsten service behind it.
Exchange RequirementsCryptocurrency ExchangeConsistency
Durable workflow engines
Five posts from building Orch8, a durable workflow engine in Rust that persists snapshots instead of replaying event history. Each one covers a subsystem with the real code: effect receipts and at-most-once dispatch, the snapshot model compared with Temporal, a Postgres scheduler on SKIP LOCKED, moving a running execution between machines, and tenant isolation.
Durable workflow engine architecture guide →
Exactly-Once Side Effects: What a Workflow Engine Can Actually Promise
A workflow engine cannot promise exactly-once effects across a network. How an eight-state effect receipt gives at-most-once and fails closed on ambiguity.
Durable ExecutionIdempotencyExactly-Once
Snapshot vs Event Replay: Two Ways to Build a Durable Workflow Engine
Snapshot vs event replay for durable execution: determinism rules, O(1) vs O(n) resume, versioning, debuggability, and what each model gives up.
Durable ExecutionEvent SourcingWorkflow Engines
Postgres as the Timer Wheel: Scheduling Workflows Without a Message Broker
A Postgres job queue with FOR UPDATE SKIP LOCKED: the real claim query, partial index, per-tenant cap, window-function trap, lease heartbeats, and its limits.
PostgreSQLJob QueueSKIP LOCKED
Moving a Running Workflow Across a Trust Boundary
Moving a running workflow to a device or another organisation: epoch fencing, capsule requirements, effect receipts that travel, and a hash-chained record.
Distributed SystemsEdge ComputingFencing Tokens
Blast-Radius Containment in a Multi-Tenant Engine
Multi-tenant isolation in a workflow engine: per-tenant circuit breakers with persisted Open state, fair claim caps, tenant-scoped signals, fail-closed routing.
Multi-TenancyCircuit BreakerIsolation
Applied cryptography, lattices, and frontend architecture
Four standalone pieces: a map of how zero-knowledge proof systems fit together, drawn from the awesome-zkp list I maintain; a source-level walk through OPAQUE password authentication in TypeScript; a Rust rewrite of the spherical code generator inside the G6K lattice sieving toolkit; and a decision guide for micro frontends versus a modular monolith from a four-team migration.
Zero-knowledge proof systems in production →
How Zero-Knowledge Proof Systems Fit Together: A Map for SNARKs, STARKs, and Folding
Zero-knowledge proof systems explained as six replaceable layers, from arithmetization to verifier, and where Groth16, PLONK, STARKs, and Nova sit on them.
Zero-Knowledge ProofsSNARKSTARK
OPAQUE Password Authentication in TypeScript: OPRFs, Envelopes, and 3DH
OPAQUE password authentication in TypeScript, traced through Cloudflare’s opaque-ts: OPRF blinding, the 129-byte credential record, KE1/KE2/KE3 layout, 3DH keys.
OPAQUETypeScriptApplied Cryptography
How I Made G6K’s Spherical Code Generator Up to 100× Faster
How incremental Gram matrix updates cut one G6K spherical-code candidate at n=128 from minutes to seconds, with the limits of the measurement stated.
RustLattice SievingPerformance
Micro Frontends vs Modular Monolith: How to Choose
Micro frontends vs modular monolith: how Module Federation composes apps at runtime, how a monolith enforces boundaries in code, and the numbers that decide.
Micro FrontendsModular MonolithReact