Throughput

Twenty thousand requests a second, held for ten straight minutes, with zero failed requests. This is what one cell does today, measured end to end through the API, not projected from the matching loop alone. The numbers below are what we have. We are actively pushing them further, and this page will move as we do.

Every number on this page is measured against the gateway, the same edge a live tenant's traffic crosses: authentication, idempotency, the journal, the engine, the acknowledgement. That is a different question from the raw matching loop's own throughput, and this page does not repeat that one.

Worth being precise about: these are requests, not trades. The traffic is 55% order placement, 35% cancellation, 10% book reads, and only the first two ever reach the journal. So of the 20,000, about 17,900 a second is what actually becomes a durable command against the engine; the rest are reads served without touching the journal at all. How many of those commands cross the book and become a trade depends on the shape of the flow, not on capacity, and this run does not report a trades-per-second figure.

#Target against delivered

A single cell, taken from 1,000 to 26,000 requests a second in steps, each held long enough to read a stable rate. Up to 20,000, delivered throughput tracks the target within 1%. Past it, the system does not fail: it queues.

20,000 req/s held 10 min 1,000 20,000 req/s 26,000 target 22,964 delivered at 26,000 target
Dashed: target rate. Solid: delivered. Three targets above 20,000 (22K, 24K, 26K) all land on the same real ceiling, about 23,000 req/s: the system queues instead of dropping requests.
Target req/s Delivered p50 ms p95 ms p99 ms max ms Errors
1,000 1,000 4.6 13.3 18.0 150 0
2,000 1,999 4.8 13.4 16.6 55 0
4,000 3,998 4.7 13.2 16.8 72 0
6,000 5,993 4.4 12.1 22.7 420 0
8,000 7,981 4.5 11.3 25.6 463 0
10,000 9,990 4.7 12.5 30.6 396 0
12,000 11,979 4.7 13.2 29.1 389 0
14,000 13,942 4.5 14.8 36.9 406 0
16,000 15,931 4.9 22.7 50.8 300 0
18,000 17,915 5.1 23.2 45.1 272 0
20,000 19,856 6.3 29.4 48.8 250 0
22,000 21,610 13.1 42.0 68.4 370 0
24,000 22,857 35.0 66.6 84.3 217 0
26,000 22,964 41.0 72.5 92.5 258 0

#Ten minutes, flat

The number we hold to is the highest point where delivered throughput tracked target and latency stayed low, not the highest point that technically survived: 20,000 requests a second, run on its own for ten minutes straight.

20,000 req/s 1,000 20,000 req/s 26,000 100 ms
p50 (green) and p99 (amber) latency against offered rate. Both sit flat through 20,000 req/s and only start climbing past it.

Held on its own for ten minutes: 19,895 req/s delivered (99.5% of target), across 11,936,893 requests. Every ten second window, start to finish, read p50 between 5.1 and 6.2 ms and p99 between 27 and 85 ms, with no drift up or down over the full run. Zero failed requests, zero rate limiting, the whole way.

#Pushed 20% past it

Immediately after the ten minute hold, the same cell took two more minutes at 24,000 req/s, 20% over the number it had just held. It delivered 22,939 (95.6% of that target). p50 rose 6.6 times, to 36.5 ms; p99 rose to 83.1 ms.

Zero failed requests. The system answered slower under deliberate overload. It did not drop work, refuse it, or fall over. That is the behavior we build for: degrade by queueing, never by breaking.

#Where the ceiling actually was

At the top of the ramp, the cell itself sat at 40 to 59% of its available cores. The load generator driving traffic against it was the one pinned, at 95 to 105% of its own, smaller capacity. The number above is a floor we measured, not the cell's real limit: the cell had capacity left on the table when the test ended.

That is exactly the gap we are closing next: a load generator built to keep up with the cell instead of leading it, so the next number on this page is the cell's own ceiling, not the generator's.

#In context

Figures other order books have published, as each team states them publicly. These are not apples to apples: different architectures, different metrics (design capacity, an API's rate limit, measured traffic), so read this as a reference point rather than a leaderboard.

Platform Published figure What it measures
Clobber 19,895 req/s Measured: sustained 10 minutes through the full API
dYdX v4 about 2,000 tx/s Chain throughput, cited by the team
Polymarket about 900 req/s Documented public API rate limit (9,000 per 10 seconds)

The dYdX figure is a chain throughput number cited publicly by that team. The Polymarket figure is the rate limit documented in its public API reference for its order book, not a stated engine capacity number. Neither was measured by us; both are stated here as each team states them.

#What's next

Two things are already in motion. The first is finding the cell's real ceiling, past what a two-core generator can throw at it. The second is running this same ramp with the full stack live around the engine, not isolated from it, since that is what every tenant actually runs against. Expect this page to gain a second number, not lose the first one.