Gabriel Loewen

Felix Canvas

A multiplayer drawing canvas whose entire backend is Felix. Shapes, cursors, presence, history and snapshots all live in Felix streams and caches — no Postgres, no Redis, no Kafka beside it.

That list is the usual build, not a strawman. A realtime canvas is normally four systems — a WebSocket tier with sticky sessions so a room's clients reach the process holding it, Redis pub/sub to fan out when they do not, Postgres for the document of record, and Kafka added later when history turns out to matter. It works; most collaborative software you have used is built that way. But the order of truth is split across all four, and Redis pub/sub carries no offsets, so a client that misses an update has no way to learn that it did — which is why reloading the page is collaborative software's universal repair. Felix Canvas keeps the merge rule those systems already use and changes only what sits underneath: one log per room, doing the live fanout and the history both, where a missed update is a gap in offsets and therefore something the client can notice and fix.

A broker does not argue for itself, so this is the application that puts Felix's properties in front of someone who has no reason to care about brokers. A publish is encoded once and delivered to five hundred viewers — measured on Azure at over a million deliveries a second with the publisher's acknowledgement holding flat at 206 µs and nothing dropped. A throttled client keeps drawing, notices its own gap in the log and rebuilds from its last offset while the other 499 are untouched. And the whole document scrubs backwards, because the log is the document.

The design is finished and the build starts at the edge. Felix is QUIC end to end, so the first milestone is the gateway that brings a browser onto that path: it terminates the browser connection, exchanges an OIDC token for one narrowed to a single room, and relays frames. It stays stateless by design. A room's truth lives in the log and the cache, which is what lets any client — new, lagging or reconnecting — recover through exactly one path.

Felix

A QUIC-based distributed event and cache system in Rust: low-latency pub/sub, durable streams, multiplexed caching, and multi-broker clustering.

It exists because some questions don't yield to reading about them. What does backpressure actually cost when one subscriber falls behind and the others aren't supposed to notice? Is a cache genuinely just a log with different semantics on top — and where does that claim break? What happens to an in-flight publish at the moment a leader's lease expires? Felix is where I find out, and the answers arrive as benchmarks and failing tests rather than as opinions.

Streams are sharded across broker owners selected with rendezvous hashing. A publish can enter through any broker and be forwarded to the owner; subscriptions follow bounded owner redirects and resume from their last offset. Durable streams use append-only log shipping, lease-fenced leaders, Leader or Quorum consistency, and caught-up replica promotion so quorum-acknowledged records survive leader failover.

Cluster metadata replicates through a Raft group embedded in the control plane, so surviving the loss of an instance no longer requires an external database; Postgres still works for deployments that prefer it. The cluster suite covers cross-broker routing, broker loss, process suspension, fencing, failover, redirects, reconnect, and single-node/cluster conformance, and the Raft suite adds a killed leader and a wiped volume. It remains in early active development.

The numbers below were measured on an Azure cluster rather than on loopback, with Microsoft Entra checking every token on the publish path. Fanout is what the design is for: a publish is encoded once and shared with every subscriber, so adding 500 of them left the publisher's acknowledgement roughly where it started, around 206 µs. Ingest scales the way the design intends — horizontally. A second broker took the cluster to 2.1× with nothing tuned. Profiling then put a number on the headroom still on the table: one QUIC endpoint task per broker gates the receive path, so a single core sets the pace while the rest of the machine stays free, and encryption — the obvious culprit — turned out to be ~8% of broker CPU against ~22% for that path. More receive endpoints per broker is what that measurement bought. Against Redpanda on the same hardware, both acknowledging from memory, Felix held a p99 of 224 µs while Redpanda's tail reached tens of milliseconds behind its periodic flush; that gap narrows on faster disks, so it says more about a common deployment than about either engine.

Three 4-vCPU Azure brokers (D4as_v5) in one availability zone, QUIC with TLS 1.3, and real Microsoft Entra ID verifying every token on the hot path — no loopback, no demo auth. The two message rates measure opposite directions and are not comparable to each other: one counts deliveries leaving a single broker, the other publishes arriving across the cluster. Ingest scales with brokers rather than with a broker's vCPU count — the receive path is a single task per broker — so a per-vCPU figure would mislead. Latency figures are medians of five trials. One provisioned session, so read it as a measurement rather than a leaderboard; full method and caveats on the linked page.

The Pale Harbor

A 2D psychological horror game set in a fog-shrouded coastal town, where you play the lighthouse keeper investigating your predecessor's disappearance.

Top-down exploration with a sanity system that distorts what you see, read and hear as it drains — hallucinations at low sanity, a day/night cycle that raises the supernatural activity after dark, and procedurally generated ambient audio. Built on HTML5 Canvas and the Web Audio API, which is a different kind of latency problem: everything has to land inside a frame.

PowerShell support for Jenkins durable tasks

I designed and implemented PowerShell execution support for the Jenkins Durable Task plugin, which provides the long-running process layer behind Jenkins Pipeline steps.

That work grew out of an earlier role contributing to the OpenStack community by continuously validating new OpenStack releases against Windows-based Nova compute infrastructure, where cross-platform process behavior and PowerShell reliability were daily concerns.

The work covered cross-platform pwsh compatibility, reliable output capture, Unicode, exit-code and error propagation, and support for legacy PowerShell behavior.