Load Testing Configuration for an HTTP Service with Downstream Integrations

# Load Testing Configuration for an HTTP Service with Downstream Integrations ## Overview We need a portable, well-documented load-testing configuration (scripts + config) for an internal HTTP service that fans out to several downstream dependencies. You will build and validate everything against a local mock server that you create — you will not be given access to our systems, data, or network. We run the final tests ourselves in our own environment. Preferred tool: k6 (JavaScript). We will also consider JMeter or Locust if you justify the choice. If in doubt, propose k6. ## System model (abstract) The target is a single HTTP service (call it `service-under-test`) that receives requests and, per request, calls one or more downstream dependencies through a gateway: - Several SOAP dependencies with high and variable latency (hundreds of ms to tens of seconds). - One or two REST dependencies that are fast (sub-second). - A cache sits in front of some lookups (keyed by a request identifier). The generator does not need to know anything real about these dependencies. It targets a single configurable base URL and sends requests that match a supplied operation mix. All downstream behavior is simulated by the mock server you build (see Deliverable 4). ## Functional requirements 1. Parameterized test data. Read request identifiers from an external data file (CSV/JSON). The file is supplied at run time; do not hardcode values. Must handle a large file (100k+ rows) without loading it all into memory if the tool allows streaming. 2. Weighted operation mix. Support multiple named scenarios (e.g. `opA`, `opB`, `opC`) each with a configurable weight, so the generated traffic reproduces a given proportion of operations. Weights come from config, not code. 3. Stepped load profile. Ramp throughput in configurable stages expressed as a percentage of a target peak RPS — default stages `25% → 50% → 75%` — with a configurable hold ("plateau") duration at each stage and a configurable ramp time between stages. Target peak RPS is a single parameter. 4. Client-side retry modes (switchable). A config flag selects client retry behavior: `none`, `immediate` (retry at once on error/timeout, N times), and `backoff` (exponential backoff with jitter). This is required — we use it to study retry amplification. 5. Configurable timeouts and connection settings. Request timeout, connection reuse / keep-alive, and max concurrent virtual users must all be parameters. 6. Two run targets. A single `BASE_URL` parameter is enough; no separate code paths. (We deploy the generator in two network locations ourselves.) 7. Metrics output. Per-operation p50 / p95 / p99 latency, error rate, and throughput (RPS), plus counts of timeouts and non-2xx responses by status code. Export results to CSV and/or JSON for our own analysis. Console summary at end of run. 8. All configuration external. Every knob (peak RPS, stages, hold time, weights, retry mode, timeouts, data file path, base URL) is set via env vars and/or a single config file. No edits to code needed to change a run. ## Deliverables 1. The load-test scripts/configuration in the chosen tool. 2. A README covering setup, every parameter, and 3–4 example invocations (baseline; a specific stage; retry mode `backoff`; higher operation-mix skew). 3. A parameter reference table (name, meaning, default, example). 4. A local mock server (small Node/Python script is fine) that simulates the downstream behavior — configurable artificial latency and a configurable error rate per endpoint — so the whole thing can be demonstrated end-to-end on the freelancer's own machine. This is how you validate your work without any access to our environment. 5. A short sample output (CSV/JSON + console) from a demo run against your mock. ## Explicitly out of scope - No access to our systems, network, data, or credentials will be provided, and none is required. Do not design anything that assumes such access. - No production endpoints, hostnames, or real data. Work entirely against your own mock. - Analysis of results, tuning of the service, and the actual test execution are done by us. ## Skills - Proven experience with k6 (or JMeter/Locust) for HTTP load testing. - Comfortable modeling weighted scenarios, staged ramps, and client retry logic. - Clean parameterization and clear documentation. English README. - Fluent Russian required. Interviewing and day-to-day communication will be in Russian. ## Ongoing collaboration This is scoped as a standalone task, but we regularly have work of this kind. A freelancer who delivers well here is a strong candidate for continued, longer-term collaboration on similar assignments. ## Screening questions (please answer in your proposal) 1. Which tool would you use here and why (one paragraph)? 2. Link to a load-testing script/config you have written (repo or snippet). 3. In k6 (or your tool), how do you implement a staged ramp with plateaus, and how do you drive throughput to a target RPS rather than a fixed number of VUs? Two or three sentences. 4. How would you model client-side exponential backoff with jitter in this tool? ## Engagement - Fixed-price, milestone-based: - M1 — mock server + baseline script running end-to-end, demonstrated to us (screen recording or call). - M2 — full staged profile, retry modes, metrics export, README + parameter reference. - Please quote a fixed price and delivery time for each milestone.