A music school that runs on software it owns.

Custom firmware on a relay board at each door. It has one job, and the whole boot order is arranged around it: the Bluetooth radio comes up before the network, because Bluetooth is the only thing that physically opens the door and it must never wait on a router.

Boot order

serial → random boot id → relay driven locked → BLE up → WiFi → HTTP → OTA

WiFi wait

bounded at ~15s, then continues without a network. It never reboots on failure

Reconnect

backoff 5s doubling to a 60s ceiling · 12 scans an hour instead of 720

Check-in

outbound every 3,000 ms, 4,000 ms timeout, carrying telemetry on the query string

Relay

duration clamped to 300–15,000 ms; auto-relock is a hardware one-shot timer and a redundant check in the main loop

Offline log

16-entry ring buffer, 12 bytes each — 192 bytes of RAM — guarded by a spinlock because the radio callback runs on another task

Image

1,324,768 bytes, 67.4% of one of two OTA slots · 54,708 bytes static RAM, 16.7% of budget

Reports

13 fields including ble_advertising — the field that distinguishes "reachable" from "can actually let someone in"

Two details worth the detour. The device has no clock, so a buffered unlock is sent as an age in milliseconds rather than a timestamp, computed with unsigned arithmetic so it survives the counter wrapping, and clamped to an hour so a wrapped value can never claim to be more recent than it is. And the flush is by sequence number, not by clearing the buffer: events queued while the request was in flight survive it, and the server de-duplicates on boot id plus sequence, so a lost acknowledgement replays harmlessly.

One uvicorn process per machine, deliberately with no worker flag — which is what makes the rest of the design coherent, because it means exactly one event loop, one connection pool and exactly two leader candidates cluster-wide.

Machines

2, always on, 1 vCPU / 2 GB each · one region, chosen to sit beside the database

Health

every 10s, 5s timeout. It reads a real row from a real table, and publishes the age of the last successful backup

Leader

a Postgres session advisory lock on a dedicated connection outside the pool, because pool recycling would silently drop it

Failover

instant on deploy; on a crash, bounded by TCP keepalive at 30 + 3×10 = 60s. No lease, no clock comparison, no split brain

Boot

pool → advisory lock → migrate → unlock, so two machines starting together cannot race the schema

Loops

five, staggered 10 / 20 / 30 / 45s at startup, four of them leader-gated

Connections

floor 8, ceiling 22, every session capped at a 5s statement timeout and a 2s lock timeout

A connection pool with a lease taken per request, and an unusual constraint: the entire codebase was written against sqlite's implicit transaction model, so the layer reproduces those semantics on Postgres rather than rewriting a thousand call sites. Reads run autocommit; the first write opens a transaction.

Pool

min 3, max 10 · 5s checkout · 30 min max lifetime · 10 min max idle

Money safety

commit attempts are counted before the commit is sent, so a request that might have committed is never auto-retried. Ambiguity surfaces as an error, never as a double charge

Migrations

append-only, never edited once applied. A machine-generated copy of the resulting schema is committed beside them and CI fails on drift

Tests

200 files across three engines — fast sqlite, real Postgres, and Postgres through the exact production connection stack

21 pages, of which 9 are lazily loaded — and the split is drawn on role, not on file size. A secretary, a rental driver or a debt chaser should not download code for a page their token can never open.

Payload

12 chunks, 1.97 MB raw. The charting library alone is 32% of all shipped JavaScript and never reaches a non-admin login

Layouts

resolved from the union of roles, not one primary role, so a second grant can never silently narrow somebody's access

Server fence

200 role dependencies across the routers, plus three middlewares that restrict by HTTP method and by path before any route runs

Allowlists

matched on path segments, not string prefixes, so granting one path cannot accidentally grant a longer one that starts the same way

Timeouts

30s globally, 120s for uploads, with three endpoints deliberately exempt because their server work cannot be cancelled

Languages

229 keys × 5 languages, typed so that a key missing any one of them fails the build. Not a lint rule, not a runtime fallback

Bluetooth

one radio manager for the process lifetime, a 6s wait for the radio to settle, an 8s scan, a 5s connect

Failure

seven distinct reason codes, each translated into all five languages, plus a diagnostic line a maintainer can read and a teacher can ignore

Releases

a version-code ledger kept by hand, because the store burns a number permanently the moment a build is uploaded

There is no payment SDK in the repository. The webhook signature is verified by hand, and the rule after that is absolute: once a signature verifies, the handler may never answer with an error, because a non-2xx makes the payment processor retry and eventually drop a booking somebody genuinely paid for. Anything wrong becomes a flag a human reads, not a rejection.

Pricing

computed in exactly one place. The edge function that takes the payment holds no rates at all and asks the server for the total

Underpayment

recomputed from the signed payload; if it is short, the booking is flagged for a secretary, never refused

Idempotency

keyed on the payment session, enforced twice: a check before insert, and a database constraint that catches a concurrent retry racing past it

Bank details

AES-256-GCM, with the row's own identity bound into the encryption, so a ciphertext cannot be moved to another row or another table

Refunds

exactly one module in the whole repository may issue one, for exactly one case, gated by an allowlist every caller re-checks

Bank file

a byte-level contract reverse-engineered from nine files the bank actually accepted — encoding, line endings, delimiter, decimal comma, quoting