March 2026 - I deployed a production Rust service to an OCI VM at 2am and watched the first real spoofing detection fire. The alert read: TRADER_A01 | TSLA | confidence: 0.99 | SPOOFING. No false positive. Real pattern. I'd spent four months getting to that moment.

Here's what it actually took.

Why Rust

The honest answer: I wanted to learn it, and I wanted something hard enough to justify the pain.

The less honest but more presentable answer: financial surveillance systems need deterministic latency. Python's GIL, garbage collection pauses, and unpredictable memory layout make it a poor fit for anything that processes order book events at microsecond resolution. Rust gives you zero-cost abstractions, ownership semantics that prevent entire classes of bugs, and latency profiles that don't randomly spike.

I'd been writing Python trading bots for a year. I understood what they were doing. I didn't understand why certain patterns kept appearing in the books just before large moves. That's what led me here.

The architecture

[gRPC stream] ──► [Detection Engine] ──► [SQLite store]
                        │
              ┌─────────┴──────────┐
              │   Pattern Modules  │
              ├────────────────────┤
              │ Spoofing Detector  │
              │ Layering Detector  │
              │ Wash Trade Detect. │
              │ Pump & Dump Detect │
              └────────────────────┘

The REST API sits on top of SQLite. The frontend is Next.js 14 with Supabase auth. The whole thing runs in two Docker containers behind nginx.

Simple in theory. Brutal in practice.

What actually broke me

Week 1-2: The borrow checker. I spent two weeks fighting the borrow checker on what should have been a straightforward detection loop. The pattern: hold a mutable reference to the detection store while iterating over orders. The compiler refused. Every workaround I tried introduced a different lifetime error.

The fix was architecturally obvious in hindsight: separate the read path from the write path. Clone what you need for detection, write results in a second pass. The borrow checker was right. My original design had a logical race condition I hadn't noticed.

Week 3: gRPC in Rust. tonic is excellent but the protobuf compile step on WSL2 hit a Windows/Linux path boundary bug. The vendored protoc binary couldn't resolve paths with mixed separators. The fix was to detect the environment in build.rs and fall back to the system protoc. Three days on a build tool issue is the kind of thing that makes you question your life choices.

Week 5: Simulation data. I needed a way to see the detection engine working without real market data. I built a simulation loop that fires synthetic spoofing/layering/pump-and-dump events every 15 seconds. Toggleable via DISABLE_SIMULATION=true. This was the right call - it let me validate the full pipeline end-to-end before touching real data.

Week 7: SQL injection in the filter API. I'd written the detection list endpoint with string interpolation for the sort_by parameter. Classic mistake. The fix was a whitelist for sort columns and params_from_iter for everything else. Found it during a self-audit. Would have been embarrassing in production.

The result

Live at http://145.241.162.208:3000. Source at github.com/Occansey/snm.

Backend: Rust/Axum, gRPC + REST, SQLite, simulation loop, Docker. Frontend: Next.js 14, Supabase Auth, WebGL GLSL plasma shader, real-time polling. Auth: all dashboard routes protected, /api/v1/detections returns 401 without a session.

The match scores for Jane Street and Citadel CVs improved significantly after I added this to the profile. The project speaks for itself in a way that a bullet point about "distributed systems experience" never could.

What I'd do differently

Run the gRPC and REST servers on separate ports from day one. I coupled them initially and untangling that cost a weekend.

Use PostgreSQL instead of SQLite for anything that might need concurrent writes. SQLite's write lock is fine for a surveillance prototype but not for production ingestion rates.

Write the detection algorithms as pure functions first, then wire them into the async runtime. Mixing async and CPU-intensive work without spawn_blocking caused tokio thread starvation in week four. Classic mistake, documented in the tokio docs, still managed to do it.

---

The code is on GitHub. The thing actually runs. That's the part that matters.