Canva Put Revocations on S3, Optiver Put Fanout on the WAL
Two teams pulled managed middleware out of a critical path and published the numbers; each replacement carries a precondition that becomes a silent outage if you skip it.
The 88% is a memory-layout win, not a storage win
Canva's saving comes from representation, not from S3. A fixed-width 16-byte record in a contiguous sorted array deletes the per-entry object headers, pointers and hashmap load-factor slack that dominate heap at hundreds of millions of entries. Lookups are binary searches over sorted in-memory arrays, not hashmap probes. That is why the structure survives the size. It is cache-line friendly and never rehashes. Memory cost is exactly length times sixteen bytes. Writers merge new chunks with conditional PUTs for optimistic concurrency. Gateways refresh with conditional GETs, so only changed 30-minute chunks cross the wire. Async workers absorb 2,000+ revocations per second. The revocation database is down to two read replicas.
The precondition goes unstated. A rolling 12-hour window only bounds memory if the access-token TTL is shorter than that window. Otherwise a revoked credential ages out of the window and silently becomes valid again. That regression throws no error and fires no alert. Long-lived tokens need a separate path. Two questions the teardown leaves open are the ones to settle before copying it: the gateway refresh interval, which is the real revocation SLA, and the behaviour when S3 is degraded. Fail open, fail closed, or serve last-known-good.
Optiver's version: the broker hop as a durability purchase
Optiver built "PG Feed", an internal NOTIFY/LISTEN implemented on the Postgres write-ahead log, to avoid the extra disk reads and writes Kafka adds to high-fanout distribution, per The Pragmatic Engineer's teardown. The same team contributed a nanosecond-precision timestamp type to Postgres, which otherwise tops out at microseconds. That is real craftsmanship, and the generalizable test is one sentence: a broker in the hot path is a purchase of durability and replay semantics. If no consumer replays from an offset and nobody needs multi-day retention, that is an fsync per message for a guarantee nobody exercises.
| Dimension | Kafka | NOTIFY/LISTEN | WAL tailing (PG Feed pattern) |
|---|---|---|---|
| Hot-path cost | Extra network hop plus disk fsync | Low, in-transaction | Low, no broker round-trip |
| Replay / retention | Native, offset-based | None, fire and forget | Bounded by WAL retention |
| Fanout ceiling | High, consumer groups | Poor, connection-bound, 8KB payload cap | High, but you build distribution |
| Failure domain | Independent of your database | Your primary database | Your primary plus slot lag |
| Ops burden | Cluster ops, well-trodden | Near zero | You own decoder, ordering, backpressure |
The failure mode to own on day one: an unconsumed replication slot pins WAL and fills the primary's disk. Without slot-lag alerting and a disk-headroom threshold, this pattern eventually takes down the database it was built to stop touching.
Calibrate the numbers before citing them
Optiver's nanosecond-class path does not compute decisions fast. It does not compute them at all. Strategy responses are memoized and burned into FPGA or ASIC behind a strict signals-to-strategy-to-execution separation, with a "retreat" system repricing thousands of options after a trade so a faster adversary cannot eat stale quotes. "Seconds ten years ago, nanoseconds now" redefines the measured unit of work, from full surface recomputation to per-quote emission out of a hardware lookup. It is not a 10^9 optimization curve, and "sub-nanosecond" is gate-level inside silicon rather than a system boundary. The same discipline belongs in any benchmark published this quarter: name the boundary, the unit of work and the noise floor. Optiver itself now says latency is no longer the moat and invests more in model quality than in shaving microseconds. A firm that measures in nanoseconds calls micro-optimization a floor cost.
A broker in a latency-sensitive path is a subscription to durability. If nobody replays from an offset, cancel it.
What to do
Classify every broker hop in your latency-sensitive fanout paths this sprint as 'needs replay or retention' versus 'needs delivery only', then prototype WAL logical decoding for exactly one delivery-only path and measure p99 against the current route.
Add replication-slot lag alerting with a disk-headroom threshold on the primary before any WAL-tailing prototype consumes its first message.
Verify that your access-token TTL is shorter than any revocation window you copy from this pattern, and route long-lived tokens through a separate check before shipping.