Active Voice Biometrics Product Architecture

This article describes the deployment architecture of Capacity Private Cloud Active Voice Biometrics: the APIs integrators consume, the external data and messaging components the platform depends on, and the hardware, software, and operational responsibilities that go into running it in production. For an executive-level introduction, see the Product Summary; for the end-to-end product walkthrough, see the Product Overview; for a capability-by-capability breakdown, see the Product Information article.

High-Level Architecture

The diagram below shows how integrators connect to the platform's voice biometrics services through its APIs and how the platform interacts with the external data and messaging components it depends on.

View full size

Figure 1: High-level solution architecture

APIs

Integrators consume the platform through four API surfaces, each scoped to a distinct concern:

Assure Biometrics API
Creates identities, enrolls voiceprints, performs verification, and manages the identity life-cycle (disable, re-enable, remove voiceprint). This is the primary integration surface for any application performing voice authentication.

Speech / LumenVox API
Provides access to the platform's speech products—Automatic Speech Recognition (ASR), Text-to-Speech (TTS), Call Progress Analysis (CPA) and Transcription. Voice biometrics deployments can reuse this surface when ASR or TTS is needed in the same workflow.

Management API
Configures deployment parameters, manages tenant and service configuration, and exposes the controls used to operate the platform.

Reporting API
Extracts session and transaction data, statistics, and audit trails—covering enrollment counts, voiceprint totals, and detailed biometric operation records. For the specific biometric reports available, see the Reporting API reference.

External Dependencies

The platform depends on four external data and messaging components, all of which are customer-provisioned. This separation keeps the data plane under customer control—important for data residency, sovereignty, and air-gapped deployments—and lets organizations align database choices with existing operational tooling. For production deployments, each component should be run as a distributed cluster outside the Kubernetes cluster for high availability and performance.

RabbitMQ
Message queue used for all transaction, audit, and management information. Services process and drain messages as data requests are handled.

Redis
In-memory cache holding session and transaction state while audio is processed by the platform's internal services. This is the component that receives and processes biometric audio in-flight.

MongoDB
Document store for enrollment and verification audio files and voiceprint models. Audio retention is configurable; retaining audio is important for audit, troubleshooting, and re-enrollment scenarios (for example, when a new DNN model is rolled out and existing voiceprints need to be rebuilt against it).

PostgreSQL
Relational store for all transactional data.

Licensing Service

The platform's containers communicate with Capacity's cloud licensing service to report product utilization. Operators must allow this outbound connection in their network and firewall configuration. In environments where outbound internet connectivity is restricted (air-gapped or strict-egress deployments), this firewall requirement should be planned for during deployment.

Web Portal

The platform ships with a web-based portal—built on the same APIs documented above—that lets operators manage deployments, view and edit configuration, perform health checks, access reports, and manage voiceprints. Organizations that prefer to integrate biometrics management into their own portals or dashboards can do so directly against the APIs without using the bundled portal.

Solution Requirements

Hardware

The platform runs in any environment that can host Linux or Microsoft Windows containers; Linux is recommended for optimal performance.

The figures below describe a representative sizing for a standalone (non-clustered) test environment processing 100 concurrent requests across three nodes (8 CPU × 8 GB memory each). Production sizing should be derived from your own cluster topology, expected concurrency, and the specific services co-located on each node.

The figures above are drawn from a standalone (non-clustered) test environment. Production sizing must be determined against your specific cluster topology, concurrency targets, and high-availability requirements.

For production, plan to provision Redis, RabbitMQ, MongoDB, and PostgreSQL outside the Kubernetes cluster. Running the data plane on dedicated infrastructure removes contention with the platform's compute pods and lets each component be sized, scaled, and patched independently. Most production deployments operate distinct test and production clusters.

Software

The platform runs on Kubernetes. The following components must be provisioned alongside it:

• RabbitMQ
• Redis
• MongoDB
• PostgreSQL
• Prometheus (optional, for monitoring) — the platform's services expose Prometheus metrics endpoints for direct scrape. Operating Prometheus itself is the customer's responsibility; the platform provides the metrics, not the monitoring stack.

Audio

Audio must be supplied as headerless, base64-encoded byte streams in one of the following formats:

• Linear signed PCM — 16-bit, 8 kHz sample rate (PCM-16)
• A-law compressed — 8-bit, 8 kHz sample rate
• μ-law compressed — 8-bit, 8 kHz sample rate

Model

The platform ships with an out-of-the-box model that performs accurately in the general case. The strongest accuracy in any given deployment is achieved when the model is calibrated and tuned against the customer's own domain-specific data. Two levels of tuning are available:

• Recalibration — adjusts score thresholds against the customer's data without retraining the underlying model.
• Fine-tuning — retrains the model's scoring back-end using production audio.

Calibration and fine-tuning can both be applied prior to production cutover, provided the customer has either voice biometric recordings from an existing system or audio samples gathered through a data-collection exercise. Calibration is a guided engagement; Capacity's team works directly with customers whose deployment has the data volume and risk profile to justify it.

Operational Responsibilities

The following activities are typically the customer's or partner's responsibility in a production deployment:

• Provisioning hardware and the container host environment
• Installing the platform's software
• Operating Kubernetes, RabbitMQ, Redis, MongoDB, and PostgreSQL
• Monitoring hardware, software, and services (for example, using Prometheus)
• Log aggregation and analysis (for example, using Datadog or Splunk)
• Stress testing the full solution in the customer environment
• Setting up and monitoring network and component latency
• Database administration, including scheduled cleanups
• Backup management

See Also

• Active Voice Biometrics Product Summary — executive-level introduction.
• Active Voice Biometrics Product Overview — channels, use cases, and the enrollment and verification flow.
• Active Voice Biometrics Product Information — capability-by-capability feature reference.
• Reporting API reference — biometric reports available through the Reporting API.