Skip to content

Does your system fail between microservices — and do your tests even see it?

QALIPSIS helps software developers model event-driven paths, scale load across zones, and validate downstream outcomes with step-level observability – in CI or at scale.

Book a demo

Can your test scenarios reach past the API layer into the system that runs behind it?

The message still has to be enqueued. The record still has to be written. The inventory decrement still has to survive a thousand concurrent writers. These failures are invisible to anything that stops at the HTTP boundary.

Let’s explore the top testing challenges developers face today – and how QALIPSIS solves them.

How far behind is your consumer before the first error appears?

  • The service returns 200 and the scenario moves on. What it does not see is that the message consumer is falling behind — processing one message per second while the producer is pushing ten. The lag accumulates invisibly until the queue backs up far enough to cause visible failures. By then, the window to catch it in testing has long passed, and the fix has to happen in production.
  • Model the message path as steps in the scenario: produce the trigger via the API, then consume the downstream message using kafka().consume or rabbitmq().consume. A join operator correlates the original request with its corresponding consumed message — so if the message arrives late, out of order, or not at all, the assertion fails at the exact step with a timestamped event. Enable step monitoring to export consumer lag as a meter over time.
  • Read more:

What actually happened after the API returned 200?

  • The API returns the right status code. The message was dispatched. But the database record was never written — or was written with a stale value because two concurrent transactions both read the same state before either committed. The bug is real, reproducible under load, and completely invisible to any test that stops at the HTTP response.
  • Place assertions as steps inside the workflow, immediately after the interaction that should produce an effect. Use a join to correlate the submitted request with the persisted outcome — database record, cached value, or downstream event — and assert on the combined record. A divergence fails at the exact step where propagation broke, with an event capturing what was observed versus expected and when it happened.
  • Read more:

What does your load test miss when it runs from a single machine?

  • Running all load from one machine produces results that reflect that origin’s network path — not the experience of users distributed across geographies. Cross-region routing, zone-specific connection pooling, and geographic service affinity all behave differently when traffic arrives from multiple origins simultaneously. A single-location test passes; a multi-zone run finds the regional session service that sits thousands of milliseconds away from half its users.
  • Deploy factories in the zones you control, assign each a factory.zone, and trigger the campaign via the REST API with a per-scenario zone percentage split in the payload. Exported meters and events are tagged by zone, so latency distributions, error rates, and throughput can be compared across regions in your existing telemetry backend — and geographic asymmetries surface before they affect users.
  • Read more:

How did a 10× latency regression ship through a green pipeline?

  • The scenario runs in the pipeline, exits zero, and the build passes. But the campaign report lives inside the tool, the JUnit file was never configured, and the only signal the pipeline received was “process exited cleanly.” A service degraded 10× under load throughout the run, every request eventually returned 200, and nothing failed the build. The regression shipped with a green pipeline.
  • Use --autostart for non-interactive runs that stop nodes after completion. In Gradle-based pipelines, the qalipsisRunAllScenarios task or a custom RunQalipsis task publishes JUnit reports configured under report.export.junit.*. The build fails on assertion breaches, the JUnit file is available as a pipeline artefact, and campaign results are retrievable via GET /campaigns/{campaign-key} for integration with your own tooling.
  • Read more:

Which step failed — and why does the report not say?

  • The campaign fails. The report says “campaign status: failed.” Which step regressed? Was it latency, error rate, or a functional assertion? Was it one minion or all of them? Without step-level data, every failed campaign triggers the same manual investigation — pull logs, compare metrics, correlate timestamps — the same archaeology every time a regression surfaces.
  • Enable monitoring { events = true } and monitoring { meters = true } (or monitoring { all() }) on the steps where signal matters, not globally, to keep data volume intentional. Export to the backend your team already queries. Configure report publishers to send Slack or email notifications on selected campaign statuses — so the right people know immediately which campaign failed and can open a step-level report rather than starting from scratch.
  • Read more:

Enterprise-grade testing for modern software

With QALIPSIS, software teams can:

Simulate real-world traffic across async, event-driven systems

Run performance and load testing for cloud-native applications

Automate testing within DevOps workflows

Gain real-time insights to boost performance and reliability

What you need to know

Build better software. Test smarter. Ship with confidence.

Start testing today