Autoscale your brokers as throughput grows

how it works

Measure once, then get answers you can trust

Nothing is guessed and nothing is hidden. The capacity numbers come from your own brokers, not from us. The recommendation is worked out the same way every time, and it comes with the full reasoning - so you can still explain it to someone weeks later.

why it's not obvious

Bigger messages cost far more than they look

One broker can handle about 44,000 small (1 KB) messages a second - but only about 439 a second when each message is 200 KB. That's why "just add more brokers" is sometimes the wrong call: with big messages you run out of data capacity, and shrinking the message is usually the cheaper fix than buying more brokers.

three examples

Three workloads, three different answers

These are real results from the tool. For each workload, the bars show how full one broker would be on each of the four things it can run out of. The amber line is the safe limit; the highlighted bar is the one you'd hit first - and the reason for the advice.

the smart shim

Route each message by topic and payload, not round-robin

Once a workload spans several brokers, where each message goes stops being arbitrary. The shim wraps the app's existing AMQP client and makes a per-message decision from rules that combine the topic and the payload, picks the target broker, and stamps a partition key on the wire (AMQP group-id plus a saas_partition_key property). The listener side runs the same rules in reverse to demultiplex a coherent per-key stream, so routing is deterministic and verifiable end to end. Type a message below and watch a rule fire.

When the fleet scales, the shim does not poll to find out. The autoscaler publishes a topology snapshot as an event on the brokers' own reserved control topics, and the shim reacts to the push. A scale-up moves only a small fraction of partition keys (rendezvous hashing), and each moved key is reassigned ordering-first: it keeps draining on its old broker until in-flight messages clear, then cuts over to the new owner, stamped with a generation (saas_gen) so the listener releases the key's stream in order. Per-key order survives the scale event.

dispatch:
  enabled: true
  default_broker: broker-bulk
  rules:
    - name: vip-orders                 # topic AND payload
      when:
        topic: "orders/>"
        payload:
          - { path: priority, op: in, value: [high, urgent] }
      route:
        broker: broker-vip
        key:   "vip.{region}"          # partition key = ordering group
        topic: "vip/{topic}"           # optional address rewrite
    - name: large-orders
      when:
        topic: "orders/>"
        payload:
          - { path: amount, op: gt, value: 1000 }
      route: { broker: broker-big, key: "big.{region}" }

cost & planning

Turn broker counts into dollars - and see what's coming

A recommendation you can take to a budget meeting needs a price tag and a look ahead. Give it your own prices and it shows the monthly cost. Ask "what if traffic doubles?" and it shows how many brokers you'd need - and where you'd run out of room.

quickstart

Up and running in three commands

Before you add your own numbers, it runs on clearly-labelled sample data that can never trigger a real change. Install it, get a recommendation, then look ahead.

# install (Python 3.11+)
python -m venv .venv && . .venv/bin/activate
pip install -e '.[dev]'

# 1. turn your performance spreadsheet into numbers the tool can read
solace-autoscale compile --workbook performance.xlsx \
    --service-classes models/service-classes.json --out models/mymodel.json

# 2. get a recommendation, with the reasoning and the cost
solace-autoscale recommend --config config.example.yaml --metrics metrics.json

# 3. see what you'd need if traffic doubles or quadruples
solace-autoscale whatif --config config.example.yaml --metrics metrics.json --multipliers 1,2,4

There's more it can do: simulate (stress-test the numbers across many workloads), monitor (watch a live broker and track how accurate its advice was), accuracy (predicted vs. what actually happened), shard-advise (suggest how to split traffic into groups), and serve (point clients at the right broker).

settings

Sensible defaults, and knobs when you need them

Everything lives in one settings file, and it warns you about typos instead of ignoring them. The defaults are cautious on purpose. Here are a few settings you're most likely to touch: