License Capacity Counting and Measurement

Overview

A product license includes two capacity caps that are measured against platform usage. This document provides the precise, stable, and reproducible definitions for how each capacity dimension is counted. These definitions are the canonical reference for license compliance.

The two dimensions of capacity are:

1. Discovered services (max_discovered_services): A monotonically increasing count of all unique services the platform has ever observed.
2. Active services (max_converted_services): A fluctuating count of services that are actively carrying a significant volume of traffic over a recent, rolling time window.

These counts are calculated by the product and reported daily to the Specaria platform as a capacity heartbeat. Understanding these definitions is essential for managing license consumption.

Dimension 1: Discovered Services

The max_discovered_services cap is based on 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)

How it works

Every unique service observed by a discovery process, whether through a gateway connector, a load-balancer connector, or the generic HTTP receiver, is added as an entry to the master discovery inventory. Each entry in this inventory counts as one discovered service.

Key Properties

• Monotonic Growth: The count of discovered services only increases. Once a service is observed and recorded, it remains in the inventory indefinitely.
• No Automatic Decay: A service continues to count toward this cap even if it stops receiving traffic. The knowledge of the service's existence is considered persistent.
• Explicit Purge Required: To remove a service from the inventory and stop it from counting against this cap, an operator must explicitly purge it from the s2r_master_discovery inventory.
• No "Active" State: The count is a simple row count of the inventory table. There is no distinction between "active" and "inactive" discovered services.

This dimension measures the cumulative knowledge the platform has acquired about the services in the API estate.

Dimension 2: Active Services

The max_converted_services cap measures the number of onboarded services that are in active production use, determined by their recent traffic volume.

Definition:

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

How it works

The platform continuously aggregates call counts for each onboarded service. A service is counted as "active" if its total number of calls over the past seven days is greater than 300.

Key Properties

• Rolling 7-Day Window: The calculation is based on a trailing 7-day sum of calls for each service.
• Automatic Decay: Because the window is rolling, a service that becomes inactive (i.e., its 7-day call count drops to 300 or below) will automatically cease to count against this cap. There is no grace period beyond the 7-day window.
• Directionality Matters: The two conversion directions for a single service are treated as distinct entities for counting purposes. A service with both a Publish facade (e.g., REST over SOAP) and a Consume facade (e.g., SOAP over REST) will be counted as two separate active services if both meet the activity threshold.

This dimension is designed to measure services that are carrying meaningful production traffic, ensuring that configured but unused services do not consume license capacity.

Comparison of Capacity Dimensions

The two dimensions measure different aspects of platform usage. A typical deployment discovers many services but has a smaller, active subset that are converted and carrying traffic.

	Discovered Services	Active Services
What it measures	Services the product has observed	Services actively carrying production traffic
Source of data	Master discovery inventory row count	Per-service rolling 7-day call sum
Threshold	Every recorded row counts	> 300 calls in the trailing 7 days
Decay	None (monotonic until manually purged)	Yes (drops out when 7-day sum falls to ≤ 300)
Directionality	Not applicable	Publish and Consume directions are counted separately

Counting Process

The platform evaluates both capacity counts automatically.

• Evaluation Schedule: Counts are computed periodically (approximately once per day) and also at product startup.
• Data Source: Both counts are calculated from the product's internal database. The discovered service count is derived from the s2r_master_discovery inventory, and the active service count is derived from rolling call aggregations.
• Persistence: The results of each evaluation are stored to allow for quick retrieval. These stored counts are the values reported in the daily capacity heartbeat to the Specaria platform.
• Fault Tolerance: The counting process is designed to be fail-soft. If a transient database error occurs during evaluation, the error is logged, and the count returns a conservative value. This prevents counting failures from impacting core platform operations.

Troubleshooting

Transient Database Errors During Counting

• Condition: The scheduled counting job fails to connect to or query the product database.
• Impact: An error is logged. The system does not crash. The counting mechanism returns a "conservative" value for the current period. The source does not specify the exact nature of this conservative value.
• Resolution: Investigate the database connectivity or performance issues indicated in the logs. The next successful run of the counting job will update the capacity values.

See Also

• Licensing Overview
• License Model
• Traffic-Driven Discovery

---

All SOAP-to-REST docs