License Capacity Counting

Overview

A license includes two distinct capacity caps, and the product measures usage against each one using a precise, reproducible definition. These definitions are stable and serve as the published reference for license compliance.

The two dimensions of capacity are:

1. max_discovered_services: The total number of unique services the product has ever observed. This count is monotonic and only increases unless an operator manually purges services.
2. max_converted_services: The number of services actively carrying a significant volume of traffic over a recent, rolling time window. This count decays automatically as service traffic patterns change.

These counts are calculated periodically and reported to the central platform via a daily capacity heartbeat.

Discovered Services (max_discovered_services)

This cap measures the total number of distinct services recorded in the product's master discovery inventory.

Definition:

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

Every service the product observes through a discovery pass, whether from a gateway/load-balancer connector or the generic-HTTP receiver, is added to this inventory and contributes to the count.

Key Properties

• No Decay: Discovery is monotonic. Once a service is observed, it remains in the inventory and contributes to the count indefinitely. A service that has not received traffic for months still counts as discovered. To remove a service from this count, an operator must explicitly purge it from the inventory.
• Every Row Counts: The count is a simple tally of the number of rows in the discovery inventory. There is no concept of an "active" or "inactive" status for discovered services.

The rationale for this model is that the discovered services count represents the total knowledge the product has accumulated about the API estate, and this knowledge does not expire simply because traffic has ceased.

Converted/Active Services (max_converted_services)

This cap measures the number of onboarded services that are actively handling production-level traffic. A service is considered "active" if its call volume exceeds a specific threshold over a rolling time window.

Definition:

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

Key Properties

• Rolling 7-Day Window: The count is based on the total number of calls for each service over the trailing 7-day period.
• Strict Threshold: A service is counted only if its call sum over the 7-day window is greater than 300. A sum of exactly 300 calls does not meet the threshold.
• Automatic Decay: Because the measurement window is rolling, a service that becomes inactive will automatically drop out of the count. If a service's 7-day call volume falls to 300 or below, it no longer consumes capacity against this cap. There is no grace period beyond the 7-day window.
• Direction Matters: The two conversion directions for a single underlying service are counted separately. A service configured for both Publish (e.g., a REST facade over a SOAP backend) and Consume (e.g., a SOAP facade over a REST backend) will count as two separate converted services if both directions meet the activity threshold.

The rationale for this model is to measure capacity based on services that are in active production use, ensuring that configured but low-traffic services do not consume license capacity.

Discovered vs. Converted Services

The two caps measure different aspects of platform usage. A typical installation discovers many services across the observed estate but converts a smaller, active subset of them for production traffic. The license caps are sized to reflect this pattern.

The following table summarizes the key differences:

	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

How Counts are Evaluated

The product computes both capacity counts on a schedule (approximately once per day) and at startup. The results are stored internally for quick retrieval.

• The discovered services count is derived from the s2r_master_discovery table in the product's database.
• The converted/active services count is derived from the rolling call aggregation data, also stored in the product's database.

Error Handling

The counting process is designed to be fail-soft. If a transient database error occurs during the evaluation, the event is logged, and the count returns a conservative value rather than causing a system failure.

See Also

• Licensing Overview
• License Model
• Traffic-Driven Discovery

---

All SOAP-to-REST docs