Farpost Pulse · Infrastructure
$ Cosmos DB rejected my seed script — and the fix wasn't in the error message
Seeding Farpost Pulse's real Cosmos DB account failed partway through, with an error that at least named exact numbers: it would have pushed total throughput to 1200 RU/s against a 1000 RU/s account cap. Three containers, each silently requesting its own 400 RU/s allocation by default, had quietly stacked up past the limit — nothing in the code, or the Cosmos SDK's own method signatures, hinted this would happen ahead of time.
The fix itself was small — explicitly provision shared throughput at the database level (1000 RU/s), and leave the container-creation calls otherwise untouched, so all three containers draw from one pool instead of each reserving their own. But re-running the script wasn't the end of it: the first, failed attempt had already half-succeeded, leaving two containers already provisioned under the old dedicated-throughput model. A code fix can't retroactively convert an already-existing resource. The database had to be deleted and recreated cleanly, then verified directly in the Azure Portal — not just by trusting a second clean run.
The fix
RU/s (Request Units per second) is Cosmos DB's normalized "cost of doing work" currency — a blended measure of read/write/query cost, decoupled from CPU, RAM, or disk, that every operation draws from a bounded budget. Shared vs. dedicated throughput is the provisioning choice that decides whether that budget is per-container or pooled. Leave it unspecified, and each container quietly reserves its own slice by default — fine until enough containers exist to blow past an account's cap, exactly what happened here.
Why this matters
The broader lesson generalizes past Cosmos DB: after applying a fix, check a cloud resource's actual live state directly, not just whether the script ran without an error this time. A partial failure can leave real infrastructure sitting in an inconsistent state that a second, corrected run won't self-heal — the kind of verification discipline that only shows up once something has actually gone wrong in production-adjacent infrastructure.
