A quota error is easy to return. The harder question is what happens to the data already written when the limit is crossed halfway through an operation.
The failure mode
Consider a pipeline that writes several keys and then exceeds the per-database key quota. A naive implementation returns ERR_QUOTA_EXCEEDED after applying the early writes, leaving the caller with a failure response and a partially mutated database.
Cacheify snapshots the affected state before the operation and restores it when a quota check fails. The response is an error, and the data looks as if the command never ran.
What is capped
The free-plan defaults are five databases per account, ten thousand keys per database and a 512 KiB maximum value. Those numbers are configurable by the operator and can be adjusted per account by an admin.
Database count is checked when a database is created. Key count and total bytes are checked on writes. A command that would cross a limit is refused before the new value becomes the visible state.
- Defaults: 5 databases, 10,000 keys per database, 512 KiB per value.
- Admins can raise or lower quotas for a single account.
- A quota failure returns 403 ERR_QUOTA_EXCEEDED and leaves the previous state intact.
Why rollback instead of preflight only
Preflight checks are useful, but they are racy under concurrent writers: two requests can each pass a check and then both commit. Snapshot-and-restore closes that gap for the operations that need it.
The trade-off is memory and latency proportional to the affected keys. That is acceptable for the command sizes the platform accepts, and it keeps the failure semantics simple: a failed write did not happen.
Try the contract yourself.
Five databases are free. Create one, mint a scoped key and send a command.