What Is A Transaction?

A transaction in LoadStrike is the full workflow you care about, not just one request. Read this page first if your workload crosses systems.

What this page helps you do

What this page helps you do

Understand when a plain request-step scenario stops being enough and a correlated transaction model becomes the better fit.

Who this is for

Teams evaluating whether their performance question is really about full workflow completion across systems.

Prerequisites

  • A baseline scenario or workflow that may cross more than one boundary or completion point

By the end

A clear mental model for deciding what should count as the start, completion, and reporting scope of your test.

Choose this path when

Start here when the workflow matters more than the first request and you need a shared language for what “complete” means under load.

Visual guide

Diagram showing ingress, stream handoff, service processing, and final completion event.
A transaction starts at the triggering action, continues through the system handoffs that matter, and ends only when downstream completion is visible.

Guide

Definition

In LoadStrike, a transaction is the business workflow that matters to the team. It might start at an API edge, continue through Kafka or another transport, and finish only when the downstream work proves the outcome really happened.

Why It Matters

A basic request-step scenario is the right starting point, but a fast first request does not always mean the system stayed healthy. Transaction testing keeps the full workflow together so you can see whether queues, workers, follow-on services, and browser steps still complete correctly under load.

How LoadStrike Models It

Start with a scenario and named steps. When the path crosses systems, add source and destination endpoints plus the shared tracking field so LoadStrike can correlate those events and report the whole outcome as one performance story.

Concept and scenario samples

Use these examples to see how LoadStrike moves from a plain request-step scenario into a correlated workflow once the business outcome completes in another system.

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

Transaction Example

using LoadStrike;

var source = new HttpEndpointDefinition
{
    Name = "orders-api",
    Mode = TrafficEndpointMode.Produce,
    TrackingField = TrackingFieldSelector.Parse("header:X-Correlation-Id"),
    Url = "https://api.example.com/orders",
    Method = "POST",
    MessagePayload = new { orderId = "ord-1001", amount = 49.95m }
};

var destination = new KafkaEndpointDefinition
{
    Name = "orders-completed",
    Mode = TrafficEndpointMode.Consume,
    TrackingField = TrackingFieldSelector.Parse("header:X-Correlation-Id"),
    BootstrapServers = "localhost:9092",
    Topic = "orders.completed",
    ConsumerGroupId = "loadstrike-orders"
};

var tracking = new CrossPlatformTrackingConfiguration
{
    Source = source,
    Destination = destination,
    RunMode = TrackingRunMode.GenerateAndCorrelate,
    CorrelationTimeout = TimeSpan.FromSeconds(30)
};

var scenario = CrossPlatformScenarioConfigurator
    .Configure(LoadStrikeScenario.Empty("orders-http-to-kafka"), tracking)
    .WithLoadSimulations(
        LoadStrikeSimulation.Inject(10, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(20))
    );

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

Transaction parts

Source and destination

Define where the workflow starts and where downstream completion becomes visible.

Tracking field

Point both sides at the same business identifier so correlation can match the workflow correctly.

Run mode

Choose the tracking run mode that matches whether LoadStrike generates the source traffic or only observes existing traffic.

Correlation timeout

Set the window for when a source action should still count as complete or timed out.