Authorization
Authorization decides what an identity may do after it proves who it is. A risky action, such as a refund, can need a person to approve it, and that can take 2 minutes or more. Keep those waits in their own queue, so that safe work does not wait behind them.
See it on the board
The same traffic runs on two boards. The simulator measured both when this page was built.
| Measure | Goal | Refunds and safe updates share one queue | Refunds go through a separate approval queue |
|---|---|---|---|
| Queue lag (Safe) | under 5 s | 13.2 s Fail | 0.8 s Pass |
| Duplicates | none | 0 Pass | 0 Pass |
| Lost writes | none | 0 Pass | 0 Pass |
| Completion time | under 260 s | 600 s Fail | 200.8 s Pass |
| Monthly cost | 12 USD/mo | 20 USD/mo | |
| p99 latency | 52 ms | 52 ms | |
| Error rate | 0% | 0% | |
| Level rules | none broken | Board is not complete Fail | Pass |
Key numbers
| Number | Value |
|---|---|
| Worker slots in one worker service, default | 64 slots |
| Lease on a queued job, default | 30 s |
| Lifetime of an access token, default | 3,600 s |
| Most steps for one agent task, default | 20 steps |
One queue · 60 of 64 workers wait for a person · safe updates wait
How it works
Authentication tells who sends a request. Authorization tells what that sender may do. The system checks each request against rules: this user may read their own orders, this service may write to this table, this agent may update tickets but not send refunds.
Give each identity the least privilege that it needs. A key that can do everything changes one leak into a full breach. Short-lived tokens with narrow scopes limit the damage. Check the rules on the server that does the action, not only in the user interface.
Some actions are too risky for an automatic rule. A large refund, a deletion or a change in production can need a person to approve it. An automated agent is a clear case: it can propose actions fast, but a person decides on the actions that move money or data.
While a person decides, no work runs, but the action still holds its place. If each pending approval holds a worker slot, a few hundred of them can stop every other job. Put approvals in a separate queue with its own capacity. Give each one a lease longer than the approval takes, so that the queue does not hand it out twice.
In the levels you send risky actions to a separate approval queue and keep safe work moving.