Capacity counting

A Specaria license carries two capacity caps, and the product measures usage against each one with a precise, reproducible definition. Publishing exactly how each is counted matters: you buy a license against these definitions, so they are stable and unambiguous.

The two dimensions are deliberately different — one is a one-way ratchet, the other decays.

---

Dimension 1 — discovered services (max_discovered_services)

Definition: the count of distinct services in the product's master discovery inventory.

discovered services = number of rows in the master-discovery inventory (s2r_master_discovery)

Every service the product has ever observed through a discovery pass — via a gateway/load-balancer connector or the generic-HTTP receiver — is recorded in the master discovery inventory and counts toward this cap.

Key properties:

• No decay. Discovery is monotonic: once a service has been observed, it stays in the inventory and keeps counting until an operator explicitly purges it. A service that stopped receiving traffic months ago still counts as discovered.
• Every row counts. There is no "active/inactive" flag on discovery — the count is simply the number of inventory rows.

The rationale is that discovery represents knowledge the product has accumulated about your estate; that knowledge does not "expire" just because traffic went quiet.

---

Dimension 2 — converted / active services (max_converted_services)

Definition: the count of onboarded services whose recent call volume exceeds an activity threshold over a rolling window.

service is counted ⇔ its total call count over the last 7 days exceeds 300

Key properties:

• Rolling 7-day window. Counting looks at the trailing 7 days of call volume, summed per service.
• Strict threshold. A service is counted only if its 7-day call sum is greater than 300. Exactly 300 calls in the window does not count (strict greater-than, not greater-or-equal).
• It decays. Because the window rolls, a service that goes quiet drops out of the count on its own. If a service served heavy traffic eight days ago but nothing in the last seven, it is no longer counted — there is no separate grace period beyond the rolling window itself.
• Direction matters. The two conversion directions of the same service — Publish (REST facade over a SOAP backend) and Consume (SOAP facade over a REST backend) — are counted as separate converted services.

The rationale is that this cap measures services actually in production use, so an onboarded service that you have configured but that is not really carrying traffic does not consume capacity.

---

Discovered vs converted — why two numbers

| | Discovered | Converted / active | |---|---|---| | What it measures | Services the product has observed | Services actually carrying production traffic | | Source | Master discovery inventory row count | Per-service rolling 7-day call sum | | Threshold | Every row counts | > 300 calls in the trailing 7 days | | Decay | None — monotonic until purged | Yes — drops out when the 7-day sum falls to 300 or below | | Direction split | n/a | Publish and Consume counted separately |

A typical install discovers many services (its whole observed estate) but converts a smaller, active subset of them. The two caps are sized accordingly.

---

How counting is evaluated

The counts are computed by the product on a schedule (about once a day) and on startup, then stored so they can be read quickly. Both counts are computed from the product's own database — discovery from the master discovery inventory, conversion from the per-service rolling call aggregation. Counting is fail-soft: a transient database error during evaluation is logged and the count returns conservatively rather than crashing anything.

These stored counts are what the daily capacity heartbeat reports to the Specaria platform, so the platform's view matches the product's. The counting definitions above are the stable published reference.

---

All Specaria SOAP to REST docs