// HACKER NEWS — CYBERSECURITY
Open Source Durable Objects for Postgres
The Durable Objects programming model as a library, on the database you already run.
Durable Objects is a good model. One object, one identity, one call at a time, and state
that outlives the request. Getting that model has meant taking on something else.
Solid Objects gives you the same model as a library. Each object has an identity, durable
state, and an ordered mailbox, and all of it lives in the SQLite, PostgreSQL, or MySQL
database you already run. No daemon, no broker, no account.
I shipped the first version two days before Shopify published
the same architecture for inventory reservations. Same conclusion, reached separately.
An app I maintain ran a cron job every five minutes. Each run loaded every active account
in the database to check whether any were due to shut down. One week of that came to 2,014
runs and 37 minutes of queue time. It turned up 8 whole accounts.
Elsewhere in the same app, a scheduled launch lived as one key per target in a key value
store. A job scanned all of them every half hour, recovered the target by parsing the key
with a regular expression, and still ran up to thirty minutes late. The controllers
enqueued a second, delayed copy of that job to cover the gap. Each piece had been added to
cover for the one before it.
I took that for a local failing until I read Brian Chesky answering a thread titled "What
happens when a host cancels with Airbnb?" It hadn't been a cancellation.
"The host did not cancel, we double-booked."
A company whose entire product is reservations had shipped the bug I was building
scaffolding against.
That left two options and I disliked both. Move onto Cloudflare Durable Objects, which is
the right model, and hand over the state, the bill, and the ability to leave. Or keep the
sweeps.
The third option was already in front of me. The deadline lived in the database. I moved
the schedule there too, so each entity arms one reminder when it's own setting changes and
wakes itself at the right time. I ran the old sweep beside it until the two agreed in
production, then deleted the cron entry.
And then Shopify published the same move:
inventory reservations out of Redis and into MySQL, one row per unit, claimed with SKIP LOCKED. Reading it was vindication of
a sort. This is not an old problem being rediscovered. It is hitting people now.