Metered OEM Licensing – Usage Reporting with Ephemeral Containers

GroupDocs.Total Product Family
1

Hi GroupDocs team,

We’re evaluating GroupDocs.Comparison for a document redlining service (SaaS for regulated software development). We’re looking at the Metered OEM license.

Our architecture runs one ephemeral container per document job — containers live for a few minutes to ~30 minutes before exiting. This means each container calls SetMeteredKey at startup and then exits well before your ~hourly reporting interval.

A few questions:

  1. Is usage reported on process exit, or only on the periodic timer? If a container exits before the first report, is that usage lost?
  2. Is the usage counter held in-memory only, or persisted to disk between reports?
  3. Is there a recommended pattern for ephemeral/serverless workloads — for example, a long-running sidecar that holds the license connection while short-lived workers do the actual processing?

Thanks,
Risto-Matti

2

Hi @ristomattip !

Thank you for evaluating GroupDocs products and the detailed architecture description.
Let me clarify all mentioned questions.

1. Is usage reported on process exit, or only on a periodic timer? Will usage be lost if a container exits early?

No usage will be lost. There is no “hourly reporting interval” in Metered implementation for all GroupDocs products

Every successful document operation triggers an immediate, synchronous API call to the billing backend — directly after each document is processed. By the time your application code returns from the comparison call, the consumption has already been reported to our servers.

The library does also contain an internal threshold-based background upload mechanism. For the per-document path your containers will follow, UploadCustomerData() is called explicitly and synchronously — the background timer is not involved.

Bottom line for ephemeral containers: as long as each document job runs to completion (success path), all consumption is reported before your process exits. Short container lifetimes are not a problem.

2. Is the usage counter held in-memory only, or persisted to disk?

In-memory only. GroupDocs products do not write any Metered state to disk as well as most GroupDocs products don’t store any internal information or states. The accumulated byte count and credit count are held in data inside a static singleton. There is no cache file, no local database, no registry entry.

This is by design and consistent across all GroupDocs products. It is also irrelevant to your scenario: because usage is uploaded after each document (see question 1), the in-memory buffer is drained on every successful operation and will contain nothing meaningful when the container exits.

3. Is a long-running sidecar or shared license proxy recommended for ephemeral/serverless workloads?

No sidecar is needed. Your architecture — one ephemeral container per document job — is a straightforward fit for the Metered license as implemented.

The recommended pattern for your use case is simply:

  1. Call GroupDocs SetMeteredKey(publicKey, privateKey) at container startup. This makes one API call to validate the subscription and mark the license as active in-process.
  2. Process your document. The library will call UploadCustomerData() internally after the operation completes.
  3. Exit the container normally.

The only network touch-points per container are:

  • One validation call on SetMeteredKey at startup.
  • One (or more, for large batches) upload call(s) during document processing.

There is no need for a sidecar to hold a “license connection,” because the Metered license is stateless from a process-lifetime perspective — each container is fully self-contained.

One practical tip for very high-frequency container spin-up: if you are launching hundreds of containers per minute, the SetMeteredKey validation call at startup adds a small network round-trip. You can reduce this by reusing container images that already have the key set in a warm-up phase, or by pooling containers that process multiple documents per lifetime. But this is an optimization, not a correctness concern.

1 Like