Modern applications do not behave like isolated endpoints.
They are composed of APIs, event streams, and services working together as transactions.
LoadStrike lets you simulate these real-world flows and measure how the whole system performs under true load.
LoadStrike is built for teams that need one runtime to test APIs, browser journeys, queues, streams, and downstream services as one correlated transaction instead of separate performance silos.
The product keeps scenario design, runtime controls, reporting, and clustered execution aligned across supported SDKs so engineering teams can reason about one workload model even when the system spans multiple stacks.
Use one product surface to validate business transactions across distributed architectures.
Simulate end-to-end transactions across multiple services instead of stopping at one request boundary.
Track how one transaction moves through APIs, queues, services, and downstream completion.
Model Kafka and event-driven workloads as first-class test paths, not sidecars around the main script.
Author scenarios in C#, Java, Python, or TypeScript with the same transaction model and runtime shape.
Start at the ingress point, follow the handoffs that matter, and keep the transaction intact for the full performance story.
Drive realistic traffic at the edge where customer workflows begin.
Keep Kafka and asynchronous handoffs inside the same measured transaction.
See where the workflow slows down as downstream services fan out under load.
This product summary answers the common architecture and rollout questions before teams move into implementation details.
LoadStrike tracks a shared business identifier across the source and destination sides of the workflow. It can extract that value from headers or JSON bodies, wait for the downstream match, and report success, timeout, duplicates, and grouped latency behavior for the full path instead of only the ingress step.
LoadStrike is positioned as a self-hosted product. Teams run the SDKs, reports, and supported clustered execution patterns on their own infrastructure, which keeps the test runtime close to the systems they are validating and gives them direct control over how the workload is executed.
One runtime surface means the same scenario, step, threshold, reporting, and correlation concepts show up across the supported SDKs. Teams do not need separate mental models for each language when they are trying to explain the same business workflow under load.
Yes. LoadStrike generates local HTML, CSV, TXT, and Markdown reports, and it also supports built-in reporting sinks for teams that want to push run data into their broader observability environment. That lets the team keep one runtime while still working with familiar backend tooling.
The workflow stays compact: define the transaction, execute load, correlate the outcome.
Model real workflows across APIs and services.
Simulate thousands of concurrent transactions.
Understand performance across systems, not just endpoints.
All SDKs follow the same transaction model.
That means teams can keep one mental model for scenarios, load simulations, runner configuration, and reporting even when services are owned by different language stacks.
using LoadStrike;
var httpClient = new HttpClient
{
BaseAddress = new Uri("https://api.example.com")
};
var scenario = LoadStrikeScenario.Create("submit-orders", async context =>
{
var step = await LoadStrikeStep.Run<string>("POST /orders", context, async () =>
{
var payload = new
{
orderId = $"ord-{context.InvocationNumber}",
amount = 49.95m
};
using var response = await httpClient.PostAsJsonAsync("/orders", payload);
return response.IsSuccessStatusCode
? LoadStrikeResponse.Ok<string>(statusCode: ((int)response.StatusCode).ToString())
: LoadStrikeResponse.Fail<string>(
statusCode: ((int)response.StatusCode).ToString(),
message: "Order submission failed");
});
return step.AsReply();
})
.WithLoadSimulations(
LoadStrikeSimulation.Inject(10, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(20))
);
LoadStrikeRunner.RegisterScenarios(scenario)
.WithRunnerKey("rkl_your_local_runner_key")
.Run();import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeResponse;
import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeRunner;
import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeScenario;
import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeSimulation;
import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeStep;
var client = HttpClient.newHttpClient();
var scenario = LoadStrikeScenario
.create("submit-orders", context -> LoadStrikeStep.run("POST /orders", context, () -> {
String body = "{\"orderId\":\"ord-" + context.InvocationNumber + "\",\"amount\":49.95}";
var request = HttpRequest.newBuilder(URI.create("https://api.example.com/orders"))
.header("Content-Type", "application/json")
.POST(HttpRequest.BodyPublishers.ofString(body))
.build();
var response = client.send(request, HttpResponse.BodyHandlers.ofString());
return response.statusCode() < 400
? LoadStrikeResponse.ok(Integer.toString(response.statusCode()))
: LoadStrikeResponse.fail(Integer.toString(response.statusCode()), "Order submission failed");
}).asReply())
.withLoadSimulations(LoadStrikeSimulation.inject(10, 1d, 20d));
LoadStrikeRunner
.registerScenarios(scenario)
.withRunnerKey("rkl_your_local_runner_key")
.run();import requests
from loadstrike_sdk import (
LoadStrikeResponse,
LoadStrikeRunner,
LoadStrikeScenario,
LoadStrikeSimulation,
LoadStrikeStep,
)
def submit_orders(context):
def run_step():
payload = {
"orderId": f"ord-{context.invocation_number}",
"amount": 49.95,
}
response = requests.post("https://api.example.com/orders", json=payload, timeout=15)
if response.ok:
return LoadStrikeResponse.ok(str(response.status_code))
return LoadStrikeResponse.fail(str(response.status_code), "Order submission failed")
return LoadStrikeStep.run("POST /orders", context, run_step).as_reply()
scenario = (
LoadStrikeScenario.create("submit-orders", submit_orders)
.with_load_simulations(LoadStrikeSimulation.inject(10, 1, 20))
)
LoadStrikeRunner.register_scenarios(scenario) \
.with_runner_key("rkl_your_local_runner_key") \
.run()import {
LoadStrikeResponse,
LoadStrikeRunner,
LoadStrikeScenario,
LoadStrikeSimulation,
LoadStrikeStep
} from "@loadstrike/loadstrike-sdk";
const scenario = LoadStrikeScenario
.create("submit-orders", async (context) => {
return LoadStrikeStep.run("POST /orders", context, async () => {
const payload = {
orderId: `ord-${context.invocationNumber}`,
amount: 49.95
};
const response = await fetch("https://api.example.com/orders", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify(payload)
});
return response.ok
? LoadStrikeResponse.ok(String(response.status))
: LoadStrikeResponse.fail(String(response.status), "Order submission failed");
});
})
.withLoadSimulations(LoadStrikeSimulation.inject(10, 1, 20));
await LoadStrikeRunner
.registerScenarios(scenario)
.withRunnerKey("rkl_your_local_runner_key")
.run();const {
LoadStrikeResponse,
LoadStrikeRunner,
LoadStrikeScenario,
LoadStrikeSimulation,
LoadStrikeStep
} = require("@loadstrike/loadstrike-sdk");
(async () => {
const scenario = LoadStrikeScenario
.create("submit-orders", async (context) => {
return LoadStrikeStep.run("POST /orders", context, async () => {
const payload = {
orderId: `ord-${context.invocationNumber}`,
amount: 49.95
};
const response = await fetch("https://api.example.com/orders", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify(payload)
});
return response.ok
? LoadStrikeResponse.ok(String(response.status))
: LoadStrikeResponse.fail(String(response.status), "Order submission failed");
});
})
.withLoadSimulations(LoadStrikeSimulation.inject(10, 1, 20));
await LoadStrikeRunner
.registerScenarios(scenario)
.withRunnerKey("rkl_your_local_runner_key")
.run();
})();LoadStrike makes the product decision clear: test whether the whole transaction survives load, not just whether one endpoint responded.
Move from raw throughput to grouped latency, failed rows, percentiles, and downstream completion visibility.
Run the platform on your own infrastructure with one transaction model across local and distributed execution.
Keep teams aligned with one product contract across C#, Java, Python, TypeScript, and JavaScript.
Model the workflow that matters, run it under load, and see how the system behaves across every handoff that counts.