Design a Load Test Plan From Real Traffic Shape Instead of a Flat Request Rate

0 upvotes

Help me design a load test for the service described below. A good plan reproduces how production traffic actually behaves, not a uniform stream of identical requests.

Use the information I give you (endpoint list, observed traffic numbers, dependencies, SLOs). If something critical is missing, ask for it first, in a short numbered list, before proposing the plan.

Produce:
1. **Workload model.** The mix of endpoints by percentage, typical payload sizes, read/write ratio, cache hit expectations, and think time. Explain which numbers came from my data and which you assumed.
2. **Load shape.** Separate stages: baseline, ramp, sustained peak, spike (a sudden multiple of peak), and soak (long, moderate load to expose leaks). Give durations and target rates for each.
3. **Dependencies.** What downstream services, databases, or third-party APIs will be hit, and whether to use real instances, stubs, or recorded responses. Warn me about anything that could cause real side effects such as emails, payments, or rate limit penalties.
4. **What to measure.** Latency percentiles (p50/p95/p99, not averages), error rate by type, saturation signals (CPU, memory, connection pools, queue depth), and the SLO each maps to.
5. **Pass/fail criteria** stated before the run, plus the signs that mean "stop the test now".
6. **Interpretation guide.** How to tell whether a bottleneck is the application, the database, or the load generator itself.

Keep the plan to what one engineer can run in a day.

SERVICE DETAILS:
[endpoints, traffic numbers, dependencies, SLOs]