Writing

20 posts on how each system works and why it's built that way, grouped by project and in reading order.

Naoto Exchange

Personal R&D, Jul 2025-present

  1. 1Moving work off the hot pathBefore any code, every step an order takes was designed from what the system needs and what the hardware does, to move as much work as possible off the hot path.Inside one service, 8 min read
  2. 2One writer for every piece of stateMost locks exist because two things can write the same data, so Naoto makes sure they never do, whether they're separate services or two threads.Across services, 3 min read
  3. 3One stream of trade reports, many copies of every balanceThe matching engine says what happened once, on a multicast stream, and every service that needs a balance builds its own copy from it.Across services, 3 min read
  4. 4Checking risk against a balance that's always behindThe risk check never sees a client's real-time balance, only a slightly stale copy, and it has to be correct anyway.Between two threads, 4 min read
  5. 5Triple-buffering client state without ever blocking a readerA risk check can't wait on whatever thread is updating a client's balance, so the balance lives in three buffers behind one atomic index.Between two threads, 6 min read
  6. 6Catching up a stale snapshot without blockingInstead of waiting on another service for a client's balance, the gateway replays the updates it has already seen onto whatever snapshot comes back.Across services, 3 min read
  7. 7When a descriptor changes mid-sendA file descriptor is just a reusable integer, so a thread sending on one while another replaces it can send an order to the wrong socket.Between two threads, 3 min read
  8. 8One order book, two data structuresAn order book needs exact-price lookups and best-price order at the same time, and no single structure is good at both, so it keeps two.Down to the bytes, 3 min read
  9. 9Designing a cache-friendly, SIMD-accelerated key-value storePicking, and then hand-building, the data structure the order book actually lives in.Down to the bytes, 10 min read

STP: Vehicle Cost Platform

Team of six at EPITA, Sep-Oct 2026

The product

  1. 1What carmakers already have, and where STP fitsBefore designing anything, we looked at how ERPs cost a car and what engineers use instead. Six pain points came out of it, and so did the rule that STP must plug into the systems already there, at a carmaker's scale.3 min read
  2. 2"What if" is answered by the backendThe dollar gains 10%: is the SUV still profitable? Margins, scenarios, price tiers and sensitivity curves, all computed server-side, so the browser never subtracts two amounts.3 min read
  3. 3A BOM that looks like a carSample data is part of the product. Six data sets, each answering one question, and a realistic SUV whose depth comes from subassemblies carrying their own parts, the way a real BOM's does.2 min read

Correct by construction

  1. 4Never add two currenciesA cost total should be rebuildable by hand from its lines, to the cent, in any currency. That rules out floats, early rounding, and adding prices before converting them.3 min read
  2. 5A number you can replayDrafts change, published versions don't, and a quote freezes every price and rate it used. So any number can be traced back to what produced it, and a number sent to someone never changes.3 min read
  3. 6The ERP never pushesSTP pulls supplier prices with a cursor, commits them before announcing them, and makes every consumer safe to run twice on the same message, so no failure leaves a price it can't account for.3 min read

Fast by design

  1. 7Recomputing only what a price touchedWhen one part changes price, only the assemblies above it are wrong. Recomputing just those takes 45 ms instead of 750 on a 20,000-part BOM, and gives the same result to the cent.3 min read
  2. 8Any instance, the same answerThree backend instances behind nginx, each with its own caches. One rule and three mechanisms keep any of them from answering out of stale memory.2 min read
  3. 9Where the time actually wentThree rounds of optimization made the backend faster at what they targeted, yet a cached read still took 220 ms. A profile showed 94% of it was re-rendering JSON that hadn't changed.3 min read

Team

  1. 10Product Owner and Scrum Master on a spec-first teamEvery structural decision written before code, feedback triaged into small increments, and a definition of done that included the full stack: how a team of six kept the loop from feedback to working software short.3 min read

CNP: Cloud‑Native Platform

Team of six at EPITA, Feb-Dec 2026

  1. 1Modeling a project's infrastructure as a graphA flat list of resources can't tell a load-bearing database from one nobody uses anymore. A dependency graph can, by walking it from the project's entry points.2 min read