Transaction load testing

Transaction load testing measures whether the full business workflow completed under load, not just whether the first request returned quickly. That means the test follows the path across APIs, queues or streams, browser steps, and downstream services until the outcome is actually visible.

LoadStrike is built for that model. It keeps the transaction explicit in code, correlates source and destination activity, and reports the latency, timeout, duplicate, and failure behavior of the whole path in one self-hosted runtime.

Who this is for

Engineering, QA, platform, and performance teams whose real performance question depends on downstream completion instead of ingress latency alone.

Why endpoint-only testing breaks down here

Endpoint-only tests stop too early when the workflow continues into queues, workers, service fan-out, or browser-driven side effects. A fast first hop can still hide delayed or failed completion later in the system.

How LoadStrike fits

LoadStrike models the transaction as a scenario, keeps APIs and downstream endpoints in the same runtime, and returns reports in HTML, CSV, TXT, and Markdown so the team can read the workflow outcome without stitching tools together.

What is a transaction?

Defines the workflow model behind LoadStrike scenarios.

Transaction vs endpoint-only testing

Shows where request-centric tests stop helping.

Quick start

Build one simple tracked transaction and run it.

Examples

Open the sample repository and high-signal docs entry points.

How is transaction load testing different from endpoint testing?

Endpoint testing measures the first request or protocol hop. Transaction load testing measures whether the full workflow finished across the systems that matter to the business, which is a broader and more operationally useful question in distributed systems.

Can a transaction start in one protocol and finish in another?

Yes. LoadStrike is designed for workflows that begin at an API or browser step and then continue through queues, streams, or downstream services before completion is visible.

Which public LoadStrike surfaces support transaction testing?

The public site documents transaction-aware workflows across HTTP, Kafka, RabbitMQ, Azure Event Hubs, NATS, Redis Streams, Push Diffusion, delegate-based stream endpoints, and Playwright or Selenium browser journeys.

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.

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.

Quick Start

Build one simple transaction, attach correlation, and run it. Use this page when you want the shortest path to a working LoadStrike test.

LoadStrike vs Apache JMeter

Compare LoadStrike and Apache JMeter across scenario design, protocol coverage, downstream correlation, browser workflows, reporting, and self-hosted operations.

LoadStrike vs k6

Compare LoadStrike and k6 across code ergonomics, protocol scope, downstream correlation, reporting depth, browser workflows, and distributed self-hosted execution.

LoadStrike and Datadog

See how the LoadStrike Datadog sink fits into transaction-aware, self-hosted load testing workflows.

LoadStrike and OTEL Collector

See how the LoadStrike OTEL Collector sink fits into OpenTelemetry-oriented reporting workflows.

Event-driven load testing

See how the transaction model applies to async systems.

End-to-end load testing

Connect APIs, browser steps, and downstream completion in one page.

Load tests around business transactions

Read the matching article on designing scenario boundaries.