Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Technical Requirements

Resource specifications and network requirements for deploying All ID.

Overview

All ID requires container orchestration infrastructure, a MySQL database, and network connectivity between components. This page defines the minimum and recommended specifications for each component.

Container specifications

Peer Service

The Peer Service is the API gateway and orchestration layer.

Specification
Requirement

CPU

0.25 vCPU (250m)

Memory

512 MB

Storage

1 GB ephemeral

Port

8080 (HTTP)

Instances

1 minimum, 2+ recommended for production

The Peer Service is stateless and scales horizontally. Add more instances to handle higher request volumes.

Facematch Service

The Facematch Service performs facial recognition and image anonymization.

Specification
Requirement

CPU

1 vCPU (1000m)

Memory

2 GB

Storage

2 GB ephemeral

Port

8080 (HTTP)

Instances

1 minimum, 2+ recommended for production

The Facematch Service requires a minimum of 2 GB memory to load machine learning models. Do not allocate less than this amount.

Database specifications

MySQL database for persistent storage of profiles, identifiers, and transactions.

Specification
Development/Testing
Production

Version

MySQL 8.0+

Aurora MySQL 3.10.0+

CPU

2 vCPU

4+ vCPU

Memory

4 GB

8+ GB

Storage

20 GB SSD

100+ GB SSD

IOPS

Best effort

3000+ provisioned

Deployment

Single instance

Multi-AZ

We recommend Aurora MySQL for production deployments on AWS due to its automatic scaling, high availability, and performance features.

Network requirements

Exposed endpoints

The Peer Service must expose the following endpoint publicly:

Endpoint
Port
Protocol
Purpose

/v1/biometric-validation-responder

80 or 443

HTTP/HTTPS

Certta infrastructure communication

Critical: The /v1/biometric-validation-responder endpoint must be publicly accessible as it is used by Certta Router Service to query the Peer Service for distributed biometric operations across regions.

Configure your load balancer to expose this endpoint with appropriate security (IP whitelisting, rate limiting, etc.).

Internal connectivity

Services communicate within your private network:

Firewall configuration

Configure firewalls to allow only necessary traffic:

Inbound:

  • Port 8080 from load balancer or clients

Outbound:

  • Port 8080 to Facematch Service

  • Port 3306 to MySQL Database

  • Port 443 to Router Service

Inbound:

  • Port 8080 from Peer Service only

Outbound:

  • None required

Inbound:

  • Port 3306 from Peer Service only

Outbound:

  • None required

Security: Deploy Facematch and Database in private networks without direct internet access. Only the Peer Service (via load balancer) should be accessible externally.

IAM permissions (AWS)

Peer Service

The Peer Service requires the following AWS permissions:

AWS Secrets Manager:

  • secretsmanager:GetSecretValue - Read database credentials and Router certificates

  • secretsmanager:DescribeSecret - Verify secret metadata

AWS Systems Manager (SSM):

  • ssm:GetParameter - Read configuration parameters

  • ssm:GetParameters - Read multiple parameters

Important: The Peer Service container must have an IAM role attached with these permissions. Without them, the service will fail to start or operate correctly.

Facematch Service

The Facematch Service does not require AWS IAM permissions. It operates independently without accessing AWS services.

Container images

Certta provides private Docker images for the components you deploy.

Contact your Certta technical account manager to obtain:

  • Container registry URL and credentials

  • Current stable image versions

  • Image update notifications

Platform compatibility

All ID has been tested and validated on:

  • AWS ECS Fargate ✅ Fully supported

  • Amazon EKS ✅ Fully supported

Other container orchestration platforms may work but have not been officially tested.

Performance expectations (TDB)

Peer Service

  • Latency: 50-200ms per request (excluding Facematch processing)

  • Throughput: 50-100 requests/second per instance

  • Scaling: Horizontal (add more instances for higher throughput)

Facematch Service

  • Latency: 100-500ms per facial matching operation

  • Throughput: 10-50 operations/second per instance

  • Scaling: Horizontal (add more instances for parallel processing)

Database

  • Query latency: 5-50ms for typical queries

  • Connections: 10-50 connections per Peer instance

  • Concurrent connections: 100+ supported

Deployment sizing

  • Peer: 2-4 instances (0.5-1 vCPU, 1-2 GB total)

  • Facematch: 2-4 instances (2-4 vCPU, 4-8 GB total)

  • Database: Multi-AZ (4+ vCPU, 16+ GB, 100+ GB)

  • Total: ~6.5+ vCPU, ~21+ GB RAM

Next steps

Last updated