Invariant-Driven Architecture: 20M transactions on a €80/mo Scaleway VM. | by Hugo Vantighem | May, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Invariant-Driven Architecture: 20M transactions on a €80/mo Scaleway VM.

Hugo Vantighem

9 min read·<br>Just now

Listen

Share

Press enter or click to view image in full size

[Part 1] presented 20 000+ durable, invariant-validated transactions per second — on a MacBook Air M3 , 8 cores, fan barely audible.<br>A laptop number is only half the story. The natural next test is whether the same architecture holds on a small, cheap public VM with network-attached storage and strict fsync(2) durability — three constraints that each, on its own, tend to move the bottleneck by an order of magnitude on most stacks. So that’s what I ran.<br>The Setup<br>VM: Scaleway POP2–2C-8G — 2 vCPUs AMD EPYC 7543 @ 2.8 GHz, 8 GiB RAM. Yes — two vCPUs.<br>Disk: SBS Block storage, 100 GB, 15 000 provisioned IOPS . Network-attached, not local NVMe.<br>OS: Ubuntu 22.04, kernel 5.15. Linux strict fsync(2) — every commit hits the SSD for real, no Apple-style controller-cache shortcut.<br>Software: the exact same codebase that ran on the M3 with NATS + Mongo + Mongo Express as the side stack in Docker<br>Price: ~€80/month order-of-magnitude — ~€54 of compute (POP2–2C-8G at €0.0735/h) plus ~€20–25 of SBS volume with provisioned IOPS. Hourly that’s €0.11 .<br>Two names, one stack<br>Two terms surface across this series. They sit at different layers, so it’s worth pinning them now.<br>Invariant-Driven Architecture (IDA) — the design philosophy. The system, end to end (ingress, sequencer, system, storage), is engineered around a single obsession: validating and enforcing business invariants on every commit, with no compromise on throughput . It’s a DDD based philosophy.<br>Atomic State Platform — the concrete implementation. The software we’re benchmarking right here — that just put down 33 091 sustained items per second on a €80/Mo Scaleway VM.<br>IDA is how. Atomic State is what. The €80/Mo VM is where. The rest of this post is how much.<br>1. The Visual Punch — 10 minutes non-stop. 20 million items. 📈<br>The first test is the one that closes the ”but does it sustain?” question forever.<br>BENCH_DURATION=10m BATCH_SIZE=1000 make cloud-bench-brokerResult, over 600 consecutive seconds on the POP2:<br>Throughput sustained — 33 091 items/s<br>Total items committed — 19 855 000<br>WAL bytes written — 7.6 GB<br>p99 round-trip — 71 ms<br>Integrity audit — ✅ INTEGRITY_OK (1 000 aggregates)<br>Durability — FSYNC-ON (Linux strict)<br>Yes, that’s higher than the laptop — and on network-attached storage, not local NVMe. SBS is block storage over the data-center fabric ; every fsync round-trips to the SBS backend before it returns. Measured fsync latency on this volume: 2.0 ms (vs 130 µs on the laptop’s local NVMe — 15× slower per call). The 33 091 items/s holds despite the network disk, not because of a fast one. Pebble’s group commit amortises that 2 ms across the whole batch — roughly 2 µs of effective fsync cost per item . That ratio is the architectural lever.<br>More on why the cloud beats the laptop on this same scenario in §4. For now, the headline isn’t the number. The headline is the steadiness .<br>I sampled the engine’s /metrics and the host’s resource counters every 15 s through the entire run. Three things every senior engineer should care about:<br>pebble_health.l0_files stays in [0, 6] the whole 10 minutes. Never higher. Compaction kicks in the moment L0 hits 6, completes before the next batch needs the slot.<br>compactions_in_progress oscillates 0 ↔ 1 — Pebble is keeping up in real time, never queueing.<br>estimated_debt_bytes never crosses 100 MB — less than 1 % of the WAL written.<br>At this scale — 34 MB/s sustained ingestion, ~20 GB of raw data committed — a mis-tuned LSM-tree triggers a Write Stall : the engine has to pause writes while compaction catches up, and the curve falls off a cliff. We see none of that. The puts counter climbs linearly from 0 to 19.85 M across the whole 10 minutes.<br>Press enter or click to view image in full size

CPU%, L0 files and debt_MB never drift outside the bands shown above during the active 10-minute window.[preflight] measured: lat_avg=2 051 µs iops=487<br>[preflight] Mac ref: lat_avg=131 µs iops=7 568 (M-series NVMe, same fio command)<br>[preflight] gate: lat_avg That’s what “industrial-grade” looks like on a VM that costs €0.11/h.<br>2. The Ceiling Demo — batch=1000 vs batch=2000<br>Now the test that tells us where the wall is. Same VM, same 1-minute window, double the batch:<br>Press enter or click to view image in full size

+2.8 % throughput for +59 % tail latency. Past 1 000 items per batch, more batching is just queueing. We’ve squeezed the disk dry.<br>Let’s do the math on what is the bottleneck. The cloud-up preflight measured 2.0 ms average fsync latency on this SBS volume (fio — rw=randwrite — bs=4k — direct=1 — sync=1, the same command everywhere). At 33 k items/s and one fsync per...