Paid client project · 2026

Apolloon race operations

I built the event infrastructure for a 24-hour relay around the wired LAN: each Electron host carries its own Node backend and writable SQLite database instead of depending on a cloud service.

Role: Software engineer · end-to-end implementation
Stack: React, TypeScript, Express, tRPC, Socket.IO, SQLite, Electron
Runtime: Electron hosts · wired LAN · local SQLite

Purpose

Race operations without a cloud dependency

The job is to register runners, manage the queue, record laps, correct mistakes, show live race state, and export results through a 24-hour event. Losing Wi-Fi, internet access, or one laptop should not turn those jobs into an outage.

Apolloon treats the event LAN as the deployment target. A single Electron laptop can run alone; when several host laptops are connected to the same wired switch, each keeps a complete writable database and catches up after a disconnect.

Standalone by defaultOne packaged host can operate an event without internet, PostgreSQL, or another managed service.
Local hosts, thin clientsBrowser-only operator laptops and displays use the LAN but do not carry a database.
Realtime where it mattersSmall Socket.IO deltas update connected screens after a successful local write.

Runtime

A desktop app that carries its own backend

LAN clientsOperator and display browsersConnect to an Electron host for race control, live state, imports, and exports

Host runtimeElectron + local Node processPackages the React UI, Express and tRPC API, Socket.IO bridge, and static files

Host storageSQLite state and operation logEach host owns its own writable data and records replication work with every local change

↓ signed UDP discovery + authenticated HTTP delta sync ↓

Pair oncePersisted host identitiesAn additional host joins from a creator URL and short pairing code, with a recovery copy before replacement

Rediscover routesHMAC-signed UDP announcementsHosts find one another again after reconnects or LAN IP changes without relying on a central server

Reconcile stateMissing operation deltas onlyAuthenticated exchanges validate compatibility and replay operations in a canonical order

Consistency

A write is more than a button click

The local server validates a command and its race-state preconditions before changing data. The application update and its immutable replication record commit in the same SQLite transaction, then the UI receives a response and connected clients receive a realtime delta.

Exactly-once retriesReusing a command ID with the same payload returns the original result; reusing it for another write is rejected.
Atomic replicationAn invalid incoming batch changes neither race data, the operation log, nor the peer's recorded progress.
Deterministic recoveryConcurrent histories can be rebuilt from a checkpoint and canonical operation order after hosts reconnect.
Durable local storageSQLite runs in WAL mode with full production synchronization on every host.

Safety

Failure handling is deliberately not magic failover

Registration, queue, and administration remain writable on every host. Timing is different: it has one assigned controller, and a planned handover only targets a reachable peer that has caught up. Apolloon does not pretend a two-laptop network split can safely elect a new controller on its own.

Guarded timing takeoverA caught-up replica can take over after controller loss with explicit operator confirmation; an uncertain recovery path warns instead of hiding possible missing timing actions.
Replication is not backupEach production host creates a verified SQLite snapshot every five minutes, with integrity checks and a SHA-256 manifest.
Version gatesPeers compare schema, replication format, app version, and release identity before exchanging replayable data.
Portable deliveryThe same self-contained Electron runtime is packaged for Linux, Windows, and macOS.

Ownership

What I designed and implemented

This is paid client work, so the source code is not public. I can describe the product and systems work I owned.

The local-first architecture, Electron runtime, typed browser and server boundary, SQLite data model, and operation-log replication path.
LAN host discovery, authenticated delta exchange, peer compatibility checks, reconnect behavior, backups, and timing handover safeguards.
Operator flows for registration, queue management, timing, corrections, imports, exports, and live race state.
Regression and end-to-end coverage for standalone writes, multi-host convergence, reconnect catch-up, invalid batch rollback, peer address changes, and timing conflicts.