An overengineered todo app

Infrastructure

Five pieces. A Cloudflare Worker running Hono serves both the SPA and the API. Postgres runs on a mini PC at home. Hyperdrive sits between them and pools connections. R2 holds the session recordings. A launchd daemon on a Mac drives OBS and uploads what it captures.

Three of those choices were not obvious, so they are worth explaining.

One worker for the SPA and the API. Splitting them means two deployments, two sets of environment variables, and CORS between them. Serving both from one worker removes all three. The tradeoff is that a bad API deploy takes the frontend with it, which for a single-user app is an acceptable failure.

Self-hosted Postgres instead of managed. Managed Postgres for this workload costs between nine and fifteen dollars a month and buys failover I do not need. The box already exists and runs other things. The real cost of this decision is not money, it is that I own patching, backups and restores, and a disk failure is an outage as long as my restore takes.

Hyperdrive rather than a direct connection. Workers have no persistent process, so a naive setup opens a fresh Postgres connection on every request. At any real concurrency that exhausts the connection limit and the database stops answering. Hyperdrive holds the pool outside the worker. This is the single component most responsible for the app staying up under load, and section three has the numbers.

The database is not exposed to the public internet. Administration happens over Tailscale. The worker reaches it through the Hyperdrive binding, so a connection string never exists in client code.

Cost and scalability

Most cloud comparisons price a generic app. That does not help, because the bill depends on which line item your workload leans on. So the first step was measuring the shape of the load.

That turns the provider question into a single question: what does each one charge to send bytes back out. Here is the same architecture priced on all four at current volume.

At this volume the gap is forty dollars a month and it does not matter. It matters at the next order of magnitude, because egress is the only line that scales linearly with use.

At a thousand users, egress alone is three thousand dollars a month on S3 and nothing on R2. That is the reason the recordings live where they live. It is not a preference for Cloudflare. This workload's dominant cost happens to be the one thing R2 does not charge for, and a workload centred on compute or storage volume would have gone somewhere else.

That projection assumes the rest of the architecture reaches a thousand users. It does not. Three things break first.

What I chose not to buy: read replicas, multi-region, managed database, autoscaling, a standby. Each one costs real money against a failure mode whose worst case is a morning without a task list. The restore path is a manual procedure and it is written down. For this blast radius that is the right amount of engineering.

Performance

One user generates no load worth measuring. So the approach was to measure what exists, then generate load until it broke. The useful number is not the latency. It is the concurrency at which the latency stops being true.

Baseline first, measured from a warm edge location, thirty runs per endpoint, against production data.

The burn-up row used to be the worst thing in the app. That chart needs total time spent per category, which is a sum across every session ever recorded against every task in it. Computed on read, that aggregate grows forever.

So it is not computed on read. A trigger maintains actual_seconds on the task row as sessions close. The work moves to write time, where it is a single row update nobody is waiting on.

The risk in that trade is real: if the trigger is ever wrong, the number is silently wrong forever. So there is a reconciliation query that recomputes the rollup from scratch and compares it against the stored value.

Then the load test. k6, three-minute ramps, against the read-heavy path a real session generates.

Finding the knee mattered less than finding the cause. The app was issuing four queries per page render where one would do. Collapsing them moved the ceiling without changing any infrastructure.

Security

This app records video of my screen while I work. That footage contains client work, private messages, and credentials that were not meant to be on screen. Everything else in the system is a task list. The threat model is almost entirely about the video.

Scope first, because a threat model that defends against everything defends against nothing. In scope: an opportunistic scanner finding the public endpoint, a stolen laptop running the daemon, a compromised dependency in the build, a leaked session cookie. Out of scope: tenant isolation, because there is one tenant; insider threat, because the insider is me; a targeted state-level adversary.

The table API needs its own explanation. One handler serves every table through /api/t/:table, which is convenient and is also the kind of endpoint that ends up in someone else's writeup with a CVE attached. It works because of what it refuses.

The table name must match an allowlist of six. Every column named in a filter or sort must appear in that table's own allowlisted column set. Every value is a bound parameter and nothing is interpolated into SQL. Anything outside those rules returns a 400 before reaching the query builder. The auth, session and account tables are not on the list and no input reaches them through this path.

And the controls I decided not to build: