CTO Workbench V2

Executable architecture review

Find where your architecture breaks.

Connect the operating assumptions. Change one boundary. See pressure propagate through the system.

↺ retry amplification 1.13×
Input3,800req/s
→
API66%utilized
→
Cache72%hit rate
→
PostgreSQL24%1,207 req/s
API async work↓
Queue776jobs/s arriving
→
Workers82%utilized
First saturation point

Workers

Safe capacity
4,652 req/s
Expected load
3,800 req/s
Headroom
18.3%

At approximately 4,652 req/s, Workers becomes the first modeled constraint.

Modeled p95 latency161 mscaller timeout 650 ms
Queue growth0/s4 min recovery
Failure exposure$24,000per modeled incident

Coupling detection

What feeds what

3 findings
  • InfoCache misses send 1,207 req/s to PostgreSQL after retries.
  • WatchRetries amplify downstream work by 1.13×.
  • WatchQueue pressure increases end-to-end latency and shrinks the retry budget.

Assumption registry

Claims the model depends on

Retry probabilityAbove 35%, downstream amplification becomes incident-scale.
12%
Cache hit rateA lower hit rate moves read pressure directly to PostgreSQL.
72%
Database capacityMust be proven at the latency objective, not at maximum throughput.
5,000 req/s
Worker throughputMust include downstream I/O and poison-message behavior.
950 jobs/s

Monitoring contract

Production invariants

InsideAPI demand < 5,200 req/sCurrent: 4,311 req/s
InsideRetry amplification < 1.40×Current: 1.13×
OutsideQueue utilization < 70%Current: 82%
InsideDatabase utilization < 80%Current: 24%
Insidep95 latency < 520 msCurrent: 161 ms
Attach the cost of failure

Modeled exposure: $24,000 per incident. Resilience investment should be compared with this boundary, not justified by availability language alone.

From diagram to operating contract

This model is intentionally small. It does not pretend to replace a load test, trace data, or an architecture review. Its job is to make coupling visible: a cache failure becomes database demand; latency becomes retries; retries become queue arrivals; saturation becomes recovery time.

The useful output is not a green score. It is a falsifiable boundary and a list of production invariants that can become dashboards, alerts, load-test targets, and incident triggers.

For the underlying reasoning, continue with deadline budgets and retry amplification, queues and overload control, database connection budgets, and error budgets as investment policy.

Prefer the focused calculators? Open the original CTO Workbench.

>