> For the complete documentation index, see [llms.txt](https://docs.caf.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.caf.io/caf-api/all-id/technical-requirements.md). # 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 | {% hint style="info" %} The Peer Service is stateless and scales horizontally. Add more instances to handle higher request volumes. {% endhint %} ### 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 | {% hint style="warning" %} The Facematch Service requires a minimum of 2 GB memory to load machine learning models. Do not allocate less than this amount. {% endhint %} ## 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 | {% hint style="success" %} We recommend Aurora MySQL for production deployments on AWS due to its automatic scaling, high availability, and performance features. {% endhint %} ## 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 | {% hint style="danger" %} **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. {% endhint %} {% hint style="info" %} Configure your load balancer to expose this endpoint with appropriate security (IP whitelisting, rate limiting, etc.). {% endhint %} ### Internal connectivity Services communicate within your private network: ``` Peer Service → Facematch Service (HTTP:8080) Peer Service → MySQL Database (MySQL:3306) ``` ### Firewall configuration Configure firewalls to allow only necessary traffic: {% tabs %} {% tab title="Peer Service" %} **Inbound**: * Port 8080 from load balancer or clients **Outbound**: * Port 8080 to Facematch Service * Port 3306 to MySQL Database * Port 443 to Router Service {% endtab %} {% tab title="Facematch Service" %} **Inbound**: * Port 8080 from Peer Service only **Outbound**: * None required {% endtab %} {% tab title="Database" %} **Inbound**: * Port 3306 from Peer Service only **Outbound**: * None required {% endtab %} {% endtabs %} {% hint style="danger" %} **Security**: Deploy Facematch and Database in private networks without direct internet access. Only the Peer Service (via load balancer) should be accessible externally. {% endhint %} ## 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 {% hint style="warning" %} **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. {% endhint %} ### 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. ``` /peer: /facematch: ``` {% hint style="info" %} Contact your Certta technical account manager to obtain: * Container registry URL and credentials * Current stable image versions * Image update notifications {% endhint %} ## 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 * Review [Architecture Overview](/caf-api/all-id/architecture-overview.md) to understand how components interact * Review [Production Guidance](/caf-api/all-id/production-guidance.md) for deployment examples * Review [Configuration](/caf-api/all-id/configuration.md) for environment variable setup --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.caf.io/caf-api/all-id/technical-requirements.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.