Transaction-Based Vs Endpoint-Only Testing

Compare endpoint-only testing with full transaction testing so you can measure the whole downstream workflow instead of just the first request.

What this page helps you do

What this page helps you do

Compare endpoint-only testing with full transaction testing so you can measure the whole downstream workflow instead of just the first request.

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

Comparison flow showing endpoint-only testing versus transaction testing.
Endpoint-only tests stop at the first response, while transaction tests follow the workflow to downstream completion.

Guide

Endpoint-Only Testing

Endpoint tests focus on whether one request returns and how quickly it does so. That is useful for isolated services, but it often stops before the business workflow is actually finished.

Transaction-Based Testing

Transaction testing follows the workflow across systems, matches the source and destination events, and reports the latency, timeout, duplicate, and failure behavior of the full path.

Practical Difference

In distributed systems, the real problem often appears after the first hop: queues back up, consumers slow down, retries rise, or orchestration breaks. Transaction-based testing exposes those downstream failures, while endpoint-only testing can leave them hidden.

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.

Transaction Model

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();

Comparison

Endpoint-only test

Measures whether one request path responded and how long it took.

Transaction test

Measures whether the workflow completed across the systems that actually deliver the business outcome.

Distributed-system signal

Captures timeout, duplicate, grouped percentile, and downstream failure behavior that endpoint-only tests can miss.