Use small experiments to reason about capacity limits and durable facts.
STEPS 19 / 23 / 26 · M5 / M6
Set the amount of work you admit.
Start work if a worker slot is free. Otherwise, enqueue it. Reject admission when both are full. Predict how many of six simultaneous jobs will be accepted.
Changing a limit resets this experiment.
Running
←
Waiting queue
Accepted0
Completed0
Canceled0
Rejected at admission0
Does accepting every job solve the problem?
When processing cannot keep up, waiting work consumes memory and time. Bound admission, execution, and the waiting queue. Async lets other work progress during a wait; it does not make CPU or database capacity unlimited.
Small Rust experiment: cargo run -p trail --example bounded_queue. This example models queue capacity; it does not implement separate worker slots.
STEPS 16 / 24 / 25 · M7 / M8
No response: did persistence fail too?
Request request-001 commits, but its successful response is lost. How many records will exist when the same request is retried?
Changing this condition resets only this experiment.
What persistence knows
No records yet
Request ID: not stored
What the client knows
No request sent yet
Does this guarantee exactly one execution?
This example reuses the same request ID at one storage boundary. A real implementation must specify its lifetime, reject different payloads under the same ID, commit the record and ID together, and recover across restart. An email or write to another service is not covered by that database transaction.
Practice: ex09 for bounded backoff and ex10 for deduplication. In stage 24, persist keys across restart and implement conditional updates.