Paid client project · 2026

Apolloon race operations

A local-first platform for running a 24-hour relay when the network, internet connection, or a host laptop cannot be assumed to stay available.

Role: Software engineer · end-to-end implementation
Stack: React, TypeScript, Express, tRPC, Socket.IO, SQLite, Electron
Context: Real client · event operations

Problem

Reliability without cloud assumptions

Operators need to register runners, manage waiting order, record laps, correct mistakes, publish live displays, and export results throughout a 24-hour event. A cloud-only design would turn internet loss into an operational failure.

The system therefore treats the local wired network as the primary environment. Event laptops discover the application automatically, while operator and display browsers connect over the LAN.

Local-firstNo internet dependency during the event.
RealtimeOperator actions patch connected displays immediately.
RecoverableMultiple hosts retain complete SQLite copies.

Architecture

One operational surface, three runtime layers

ClientsOperator screensRace control, imports, corrections and exports

ClientsLive displaysRankings, active runner and public race state

Client stateReact QuerySnapshot cache patched by realtime events

↓ tRPC + HTTP + Socket.IO ↓

ServerExpress + tRPCValidated commands and export endpoints

StateSQLite primaryRace invariants and transactional writes

DesktopElectron packageStarts and serves the complete local application

↓ discovery + replication + voting ↓

Host AWritable primaryCurrent authoritative database

Host BHot standbyFull local replica and forwarded writes

Host CVoting standbyEnables safe promotion without split-brain

Ownership

What I designed and implemented

This is paid client work. The source code cannot be shared publicly, but the architecture, operational constraints, and my contribution can be described.

The typed browser/server boundary, SQLite state transitions, realtime cache bridge, and operator workflows.
CSV imports, structured exports, live public displays, LAN host discovery, and desktop packaging.
Replicated hot-standby behavior with a three-host voting rule to prevent unsafe promotion after a network split.
Regression and end-to-end tests around race completion, waiting order, runner status, historical labels, and realtime behavior.

Key engineering decision

With only two hosts, neither side of a network split can prove it has the authoritative copy. Automatic failover is therefore deliberately limited to three voting hosts. Refusing an unsafe promotion is better than accepting two diverging primaries.

Engineering

Operational constraints shaped the product

Failure containmentEach host keeps a full local copy, so a single laptop is not the only place where race state exists.
Visible authorityThe primary/standby model creates one explicit writer instead of relying on optimistic multi-writer conflict resolution.
Operator safetyRace-state transitions live behind validated server procedures and regression tests rather than UI assumptions.
Portable deliveryElectron packages the server and frontend into an event-ready desktop application with no cloud setup.