When To Use LoadStrike

Use LoadStrike when your real performance question is about a workflow across systems, not just one endpoint. It is most useful when completion happens downstream.

What this page helps you do

What this page helps you do

Use LoadStrike when your real performance question is about a workflow across systems, not just one endpoint. It is most useful when completion happens downstream.

Who this is for

Engineers deciding how to frame the workload before they choose transports, thresholds, or reports.

Prerequisites

  • A workflow where business completion matters more than the first request alone

By the end

A clearer definition of what the transaction should mean for this workload.

Use this page when

Use this page when the team needs to agree on the workload model before debating transport, threshold, or reporting details.

Visual guide

Decision flow showing when LoadStrike follows downstream workflow completion.
LoadStrike is most useful when the performance question depends on downstream completion, not only the first request.

Guide

Best Fit

LoadStrike is a strong fit when a plain request-step scenario is not enough and business latency depends on more than one hop. That includes APIs that publish to Kafka, services that fan out to workers, browser journeys that trigger async processing, or any path where success is only visible later.

Team Fit

It is built for engineering, QA, platform, and SRE teams that want code-first tests, aligned SDK behavior, and one runtime and reporting model across distributed system boundaries.

When Simpler Tools Are Enough

If the workload is purely request-response and the only question is endpoint throughput or latency, an endpoint-focused tool can still be a reasonable choice. LoadStrike becomes more valuable when the system only feels complete after a correlated downstream result arrives.

Concept and scenario samples

Use these examples to connect the concept on this page back to the scenario and reporting model that the runtime actually exposes.

If you run these examples locally, add a valid runner key before execution starts. Set it with WithRunnerKey("...") or the config key LoadStrike:RunnerKey.

When LoadStrike Fits

using LoadStrike;

var httpClient = new HttpClient
{
    BaseAddress = new Uri("https://api.example.com")
};

var scenario = LoadStrikeScenario.Create("read-order", async context =>
{
    var orderId = $"ord-{context.InvocationNumber}";

    var step = await LoadStrikeStep.Run<string>("GET /orders/{id}", context, async () =>
    {
        using var response = await httpClient.GetAsync($"/orders/{orderId}");

        return response.IsSuccessStatusCode
            ? LoadStrikeResponse.Ok<string>(statusCode: ((int)response.StatusCode).ToString())
            : LoadStrikeResponse.Fail<string>(
                statusCode: ((int)response.StatusCode).ToString(),
                message: "Order lookup failed");
    });

    return step.AsReply();
})
.WithLoadSimulations(
    LoadStrikeSimulation.Inject(10, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(20))
);

LoadStrikeRunner.RegisterScenarios(scenario)
    .WithRunnerKey("rkl_your_local_runner_key")
    .Run();

Good fit signals

Plain scenario first

Start with a simple request-step scenario when you only need to validate the first runnable path.

Cross-system workflows

Move into tracked source and destination definitions when the workflow spans APIs, queues, services, or browser steps.

Business completion

Choose LoadStrike when the important metric is whether the transaction finishes, not only whether ingress accepted the call.