Most performance claims in the rules-engine market are unfalsifiable. Phrases like “sub-second response times”, “massive scale”, and “enterprise-grade throughput” are common but give little help when writing a capacity plan.
To get real numbers, we measured the behavior of DecisionRules on Kubernetes, using decision tables as a test case. All numbers in this document are based on real load tests, no theoretical guesses.
To give you a quick overview:
- A medium-complexity rule is solved in under 3 milliseconds, on average.
- Under maximum load, the same platform processes over 100,000 decisions per second, with an average latency of 10 milliseconds.
- Throughput and latency are not always mutually exclusive — given proper horizontal scaling.
Verified Performance Metrics Summary
| Metric | Value | Conditions | |
|---|---|---|---|
| Median latency – decision tables | 2.94 ms | 500 req/s, 3 case avg (small/middle/large) | |
| Median latency – decision trees | 2.59 ms | 500 req/s, 3 case avg | |
| Median latency – script rules | 7.84 ms | 500 req/s, data transformation use case | |
| Median latency – workflows (small) | 3.35 ms | 500 req/s, 3 case avg | |
| Median latency – workflows (medium/large) | 4.98 ms | 500 req/s, 3 case avg | |
| Blended median latency | 3.83 ms | 500 req/s, 13 test cases | |
| Blended p95 latency | 5.29 ms | 500 req/s, 13 test cases | |
| Best case – small decision tree | 1.51 ms | Package-delivery-pricing example | |
| Worst case – script rule p95 | 10.58 ms | Data transformation | |
| Worst case – non-script rule p95 | 9.87 ms | Sequential decision flow |
What We Tested and How
- Deployment: Kubernetes cluster (no auto-scaling enabled)
- Region: Load generators and cluster in same AWS region
- Validation: Only requests that returned 200 OK and passed content validation were counted as successful
Rule types tested:
- Small/middle/large decision tables
- Script rules for data transformation
- Small and large workflows
- Decision flows triggering 1–10 rules per execution
All requests passed validation and had error rate of 0%
What we tested on
Of course the raw number don’t mean much without the specifications, so here they come:
Test environment
| Application nodes | 3 × c7g.xlarge (4 vCPU, 8 GiB RAM) |
| In-memory cache | Enabled |
| Redis | cache.t4g.micro |
| Load generator | 1 × m7i.2xlarge (K6) |
As mentioned before, the tests were running in a fixed AWS environment with 3 application nodes ( Graviton (ARM) instances ) . And one additional node for Redis , which for the purposes of this test doesn’t need to do much work since we have In memory cache enabled, meaning we keep our rules in the memory ( there are no updates to the rules during the tests, so the redis load stays low ). Everything was tested from a K6 instance running in the same place as to not introduce additional noise into the results.
How to use these numbers
If you are sizing a deployment. The maximum throughput achieved was over 35 000 requests per second per node. Of course this will depend on the actual rules that would be running in your decisionrules and the performance requirements of your application. We can always help you to determine the right configuration and scaling for your particular case.
If you have a latency SLA. For all the rules in our tests the p95 stays under 10ms when sending 500 ms per second. Again as mentioned above this number can be tweaked by changing the configuration according to specific rules or introducing scaling.
If you are designing decision logic. Consolidate. Calling 10 rules inside a flow can cost only about 2 times more time than evaluating a single rule, because you pay the network round-trip once.
If you are comparing engines. Compare percentile distributions, not averages. An average is easy to win by being fast on the happy path. The p50-to-p95 spread tells you whether the system queues, and queueing is what breaks production systems.
Scope and Limitations
These results are based on a fixed configuration and in-region deployment. Here are some important facts to consider:
- Payload size — when pushing 10+ million requests per minute, the size of the data matters.
- Network latency is not included — cross-region calls will add time.
- These are real measured results, not theoretical maxima.
- They apply to the specific rule set we used and the environment tested.
Conclusion
These real-world tests show that DecisionRules can scale to high throughput with consistent low latency, zero errors, and solid reliability.
Whether you’re evaluating a new engine, designing an enterprise-level system, or planning for millions of daily decisions, these measurements can bring clarity and confidence to your decision-making.
Ondřej Brejla works at DecisionRules, where he helps companies design and implement decision automation solutions that bring business rules out of hard-coded systems and into a form business teams can manage directly. He focuses on business rules, system integrations, and helping technology teams design processes where the bussines users can take ownership of parts of the applications.
