Periodic demand

Plan for the users you serve and the moments they sign in.

A customer portal can have a large registered population while each person visits only occasionally. A document release or periodic customer action can concentrate demand into a short period.

Plan your implementation

Demand has a timing pattern.Illustrative, not a capacity benchmark

Licence basisEdition + agreed deployment scope

No charge per registered user. Infrastructure, capacity and operations are planned separately.

The business situation

A large audience returns at predictable moments

A customer portal is used occasionally through the year. When new documents become available, many people return to sign in. The team needs to plan both the licence budget and operating capacity.

01 / Working model

Give the licence budget a clear basis

ProAuth licence prices do not increase per registered user. Select the edition and deployment scope that fit your service, then plan infrastructure, messaging, implementation and optional support separately; Basic Support is included during an active subscription or perpetual upgrade coverage.

This is particularly relevant when the number of accounts says little about routine activity. Licence expenditure has a defined basis even as your user population changes.

Three separate planning inputs.

Registered accounts: Describe your user population.
Requests and peaks: Determine the operating capacity to validate.
Edition and deployment scope: Define the licence basis.

What your team gains

Budget the licence independently of users: Use flat-rate licence pricing within the agreed scope.
Match capacity to demand: Use telemetry and configured scaling policies to adjust resources around busy periods.
Plan for returning users: Choose sign-in and recovery processes that occasional users can follow.

Make demand visible to operators

ProAuth exposes logs and metrics through OpenTelemetry, with tracing available when needed. Operators can use telemetry and configured Kubernetes scaling policies to adjust application capacity.

For scheduled activity, additional capacity can be made available before notifications are sent. Plan and validate the complete path, including database capacity, messaging and shared services, against representative demand.

Customer portal deployments have used ProAuth through recurring busy periods. The useful pattern is ongoing observation and capacity management; the right configuration depends on your workload.

Organise data and recovery around the service

Separate user-store databases provide a boundary for managing identity data and backups. Coordinate identity recovery with application data, configuration and encryption keys so the restored service remains consistent.

For occasional users, also evaluate enrolment and account recovery. Choose flows that fit your audience and protection requirements, and establish what support will do when self-service cannot restore access.

Details for your decision.

Let’s plan your implementation.

Estimate registered accounts, sign-ins over a busy period and concurrent requests separately. Review a representative workload and the operators' scaling and recovery procedures.

Discuss your portal's demand pattern