Performance & Scaling

Rule execution capacity is determined by the HPS worker fleet. This page explains the sizing model and the values that control it.

If you deploy with the Rulebricks CLI, a performance tier (Small, Medium, or Large) sets all of these values consistently for you. Tune by hand only when you need to go beyond a tier.

The Sizing Model

Workers are single-threaded processes doing CPU-bound rule evaluation. Three ideas hold the model together:

1. Partitions are the concurrency ceiling. The solution Kafka topic's partition count (rulebricks.hps.workers.solutionPartitions) is the maximum number of workers that can consume in parallel. It is a ceiling, not a worker quota: idle partitions are effectively free, so the defaults carry roughly 2x headroom over the maximum worker count, because partition counts can be raised but never lowered.
2. Workers scale out, not up. Each worker can use up to one full CPU core. The default request is lower so a warm fleet packs efficiently, and bursts add replicas for throughput.
3. KEDA scales on backlog. Workers run as a Deployment scaled by KEDA on Kafka consumer lag, so scale-out creates pods in parallel and delivers burst capacity in seconds.

Two rules must always hold:

• keda.maxReplicaCount must stay at or below solutionPartitions; a worker beyond the partition count would sit idle.
• solutionPartitions must match the partition count of the actual solution topic, whether reconciled by the chart from kafka.topics or pre-created on an external Kafka cluster.

The CLI validates both rules before anything reaches your cluster.

Worker Values

KEDA Autoscaling

Lag is measured in messages. HPS splits bulk requests into bounded chunks, so each message represents roughly 50 to 150ms of work, and the default threshold of 50 biases toward early scale-out during bursts.

Scaling Beyond the Defaults

# Higher-throughput configuration
# (update kafka.topics partitions to match solutionPartitions)
rulebricks:
  hps:
    replicas: 4
    workers:
      solutionPartitions: 96
      keda:
        minReplicaCount: 12
        maxReplicaCount: 96

Burst Pools, Priorities, and Image Pre-Pull

The chart is designed to keep stateful and ingress infrastructure stable while worker capacity scales elastically:

The CLI's cluster-setup templates use a burst node pool labeled and tainted rulebricks.com/pool=burst. Worker pods tolerate and prefer that pool, while critical services such as Kafka, ClickHouse, and the database can use the release critical class. If you run a fixed cluster with no autoscaler or dedicated burst pool, consider disabling global.priorityClasses.enabled or explicitly setting worker priority to match your platform policy.

Other Scaling Surfaces

Throughput also depends on how clients call the solve API: bulk payloads amortize network cost, and the request size limits describe the byte-first admission model.

To verify a deployment under load, use the benchmarking toolkit (opens in a new tab) in the helm repository.