Routine steps
Classification, extraction, validation, routing, and repair do not always need the most expensive model in the stack.
500 RPS Diagnostic Packet
A concrete packet for Railway, Cloudflare, Postgres, and 500 RPS readiness.
This is the pre-sale proof surface for teams that need burst capacity without runaway idle cost. It shows what the USD 99 diagnostic would inspect before recommending scaling, load testing, monitoring, alerts, or auto-recovery changes.
Model Cost And Privacy
Use frontier models only where they matter.
Flev workflows can route routine, structured steps to local or private small models while keeping stronger models available for complex reasoning.
Reviewable routing
Teams should be able to see which model handled which step, why fallback exists, and who can approve changes.
Small-model ready
Better Call evidence shows tool-call accuracy improving from 73.4% to 83.8% on 3,625 granite4.1:3b BFCL v4 cases.
Diagnostic scope
The packet turns a scaling ask into reviewable evidence.
The first pass stays read-only: collect facts, identify missing measurements, and decide which small tests prove whether the system can safely reach 500 RPS.
Traffic shape
Separate steady-state, burst windows, cacheable paths, authenticated paths, background jobs, and webhook or ingest spikes.
Runtime boundary
Map Railway services, process types, concurrency limits, health checks, restart behavior, and idle-cost controls.
Edge and data path
Review Cloudflare caching, rate limits, origin shielding, Postgres connection limits, slow queries, pool sizing, and migration risk.
A useful 500 RPS answer should not be a guess. It should show which signals prove readiness, which gaps block confidence, and which change needs explicit approval.
01
Acceptance evidence table
| Area | What to inspect | Acceptance signal |
|---|---|---|
| Load test | Run a staged read-only test against safe endpoints with ramp, hold, and burst phases. | P95 latency, error rate, CPU/memory, and queue depth remain inside the agreed threshold at 500 RPS. |
| Postgres | Check connection pool usage, slow queries, lock waits, index coverage, and burst behavior under representative reads/writes. | No pool exhaustion, lock pileups, or query plan regressions during the target burst. |
| Railway | Review service sizing, autoscaling or manual scale plan, health checks, restart policy, and cost at idle. | Burst path is documented, rollback is clear, and idle cost does not require overprovisioning. |
| Cloudflare | Check cache rules, bypass paths, rate limits, WAF noise, origin response headers, and observability. | Cacheable traffic stays at the edge and protected origin paths remain measurable. |
| Recovery | Review alert thresholds, synthetic checks, deployment rollback, and auto-recovery limits. | Operators know which failures self-heal, which page a human, and which require rollback approval. |
02
Example diagnostic note
This is the shape of the first paid answer: short enough to read quickly, specific enough for an engineer to challenge, and explicit about what is not proven yet.
Likely first constraint
Postgres connection pressure and cache-bypass routes are checked before increasing Railway process count. Scaling app workers first can make the database failure arrive faster.
Safe validation path
Start with a read-only ramp on public cacheable routes and one authenticated representative route. Stop when P95, 5xx rate, pool usage, or origin CPU crosses the agreed guardrail.
Approval boundary
No production cache-rule change, Railway scale change, migration, or auto-recovery action runs inside the diagnostic without explicit approval.
Next paid scope
If the evidence supports it, the next scope can implement the load-test script, Cloudflare rules, Railway scale plan, Postgres pool tuning, and alert thresholds.
03
Paste this into the first email
The quickest scope confirmation comes from a short, concrete message. These bullets are enough to decide whether the USD 99 diagnostic fits.
- Product surface and stack: Vue3, Ruby/Sinatra, Postgres, Railway, Cloudflare, or the closest equivalent.
- Target traffic shape: current RPS, target 500 RPS burst duration, cacheable versus authenticated paths, and any excluded endpoints.
- Current evidence: Railway metrics, Postgres limits or pool size, Cloudflare cache rules, recent logs, slow queries, or incident notes.
- Business boundary: what cost ceiling, downtime risk, and approval rule should stop the test.
04
Runbook skeleton
- Confirm the safe endpoints, traffic shape, and excluded destructive paths before any load test.
- Capture baseline latency, error rate, Postgres pool state, Railway metrics, and Cloudflare edge/origin split.
- Run staged ramp, hold, and burst tests; stop immediately on agreed error, saturation, or cost guardrails.
- Classify bottlenecks by app code, Postgres, Railway process sizing, Cloudflare caching, or missing monitoring.
- Return a risk-ranked change list with explicit approval boundaries for deploy, scale, cache, alert, or recovery changes.
Commercial boundary
What the USD 99 diagnostic can honestly promise.
The packet is intentionally narrow: it makes the next scaling decision safer, but it does not pretend to be an unlimited infrastructure migration.
Included
One service or app surface, one target traffic shape, one evidence table, one load-test plan, one runbook, and one paid-scope recommendation.
Needs separate scope
Production mutation, full redesign, long-running monitoring implementation, database migration, incident response retainer, or guaranteed 500 RPS capacity.
Revenue rule
Interest, intake, or a draft invoice is not counted as income. The experiment only counts cleared payment evidence.
Flev DevOps
Send one scaling path. If it fits, get the USD 99 500 RPS diagnostic next.
Send the failing or scaling path, the target burst shape, and what would count as safe enough to proceed. We will confirm whether it fits the fixed USD 99 diagnostic before any payment request.