IDV Installation
This section describes how to install and deploy the IDV Platform, including its dependencies, internal services, and recommended deployment strategies.
Architecture Overview
IDV is a set of interconnected services that integrate with Regula Document Reader API and Regula Face API. Its modular design allows for flexible deployment — from a single instance setup to distributed high-availability environments.
External Dependencies
Ensure the following third-party components are available before deploying IDV.
Dependency | Description | Options | Requirement |
---|---|---|---|
Database | Stores primary data for all services. | MongoDB 4.4+ / MongoDB Atlas (recommended) | Required |
Message broker | Handles asynchronous communication and background job processing. | RabbitMQ / AmazonMQ 3.x+ / Kafka 3.7+ / Redis / Valkey 7.0+ | Required |
Storage | Stores files, images, and processing results. | S3 or S3-compatible (MinIO) / Local file system (NFS) | Required |
Vector database | Supports similarity search and vector-based queries (needed for the Profile module). | OpenSearch 2.19.0+ / MongoDB Atlas | Optional |
Document service | Provides document data extraction (needed for document processing). | Regula DocumentReader 8.1+ | Optional |
Face service | Enables face detection, matching, and liveness checks. | Regula FaceAPI 7.1+ | Optional |
Metrics server | Collects metrics (StatsD protocol) for monitoring, observability, alerting. | Prometheus / statsd_exporter | Optional |
Internal IDV Services
Service | Description | Scaling out | Scale metrics | Hardware (per instance) |
---|---|---|---|---|
API | Main HTTP entry point, proxies requests to other services. | Yes | idv_api_http_duration , idv_api_http_request_total |
CPU: 2 vCPU RAM: 2 GiB |
Workflow | Executes workflows and coordinates communication between services. | Yes | Queue size, processing delay | CPU: 2 vCPU RAM: 2 GiB |
Scheduler | Executes scheduled tasks (data cleanup, workflow reload, periodic jobs). | No | - | CPU: 1 vCPU RAM: 1 GiB |
Audit | Logs all significant system events. | No | - | CPU: 1 vCPU RAM: 1 GiB |
Special Requirements
- The Face Processing Service should run on a GPU for optimal performance.
- The GPU mode is memory-intensive; it is recommended to prioritize larger GPU memory over raw compute performance.
Recommended setup (observed in production):
- AWS EC2 with NVIDIA Tesla T4 GPUs
- 16 GB GPU memory → supports up to 4 parallel workers
Deployment Options
Single instance setup
A minimal setup can run all services on one machine using Docker Compose.
Prerequisites:
- Valid license file in the same directory as
docker-compose.yaml
. - Prepared IDV config (
config-idv.yaml
) and Document Reader config (config-reader.yaml
). - Integration with Face Processing Service and Document Reader with sessionAPI enabled.
Configuration files:
config-idv.yaml
— shared IDV configuration.config-reader.yaml
— Document Reader configuration.docker-compose.yaml
— deployment file.
This setup is suitable for development or demo environments.
Distributed environment setup
For production-grade deployments, IDV should be deployed in a distributed environment to ensure high availability, scalability, and fault tolerance.
Key benefits:
- Fault isolation between services
- Flexible scaling of heavy-load components
- Improved performance under high traffic
- Easier observability and monitoring
Recommended architecture includes:
- API — entry point for all traffic
- Face Processing Service — GPU-enabled nodes
- Document Reader Service — independently scalable
- Message broker — RabbitMQ, AmazonMQ, or Kafka
- Databases — MongoDB Atlas + optional Vector Search (OpenSearch)
- Storage — S3 or NFS
- Monitoring — Prometheus-compatible metrics
Deployment considerations:
- Deploy each service in dedicated containers or Kubernetes Pods.
- Use load balancers for traffic distribution.
- Use persistent volumes and managed storage (MongoDB Atlas, S3).
- Configure metrics and alerts per component.
AWS Cloud setup (HA)
For high availability (HA), IDV can be deployed on AWS with managed services:
- Database: MongoDB Atlas
- Message broker: AmazonMQ
- Container orchestration: Amazon EKS (with Karpenter)
- Storage: S3
- Vector database: MongoDB Atlas
This setup leverages AWS-managed infrastructure for scalability, resilience, and fault tolerance.