Deployment
Traveler Identity Service (TIS) is delivered as a self-contained platform that runs on the customer's infrastructure. This page describes what the integrator / customer provides, what Innovatrics packages and operates inside the deployment, and the high-availability and disaster-recovery options.
What the customer provides
The customer (or system integrator deploying on their behalf) is responsible for:
- Database infrastructure — a SQL database (Oracle, PostgreSQL, or MS SQL). Single server, DB cluster, or managed cloud DBaaS is acceptable. DB administration, backups, and recovery — and replication between production and DR sites — are the customer's responsibility.
- Network and TLS — TLS certificates for the public ingress, network connectivity between sites (for DR / Central → Local sync), and firewall policy.
- Compute infrastructure — bare metal, virtual machines, or managed Kubernetes. Innovatrics standardizes on Kubernetes as the deployment platform; sizing is captured per deployment.
- Storage — disk for the SQL database, MinIO object storage (or a compatible service), and Apache Ignite cache persistence.
- DR site — when running active-active or active-passive across two data centers.
What Innovatrics packages
Inside the Kubernetes deployment, Innovatrics packages and operates the following stack:
| Concern | Component |
|---|---|
| Ingress / TLS termination | Traefik (or NGINX Ingress) |
| Service mesh / mTLS / latency-aware routing | Envoy + Linkerd |
| Identity store + ABIS persistence | SQL database (Oracle / PostgreSQL / MSSQL) |
| Biometric image / binary storage | MinIO (S3-compatible) — local instance per regional site, replicating to central |
| Distributed template cache | Apache Ignite (separate caches per modality: face, fingerprint, iris) |
| Cluster coordination | ZooKeeper |
| Cache durability | Cache Persistence — backs Ignite state to disk; survives restarts without full gallery reload |
| Async messaging | RabbitMQ — enrollment events, deduplication jobs, workflow notifications |
| Observability | Jaeger + OpenTelemetry (tracing), Grafana (metrics) |
| Secrets management | Vault — credentials, certificates, encryption keys |
The integrator does not operate these components individually — they are packaged together as the TIS deployment.
High-availability modes
Traveler Identity Service can run in three high-availability modes:
- Active-Active — two sites processing requests concurrently. Both can independently serve enrollment and matching; failures at one site leave the other operational.
- Active-Passive / single-site — primary site serves traffic; passive site stands by.
- Without HA (single-server) — for smaller deployments where HA is not required.
Cluster design
The ABIS cluster = ABIS Management Servers + ABIS Matching Cluster. Nodes are configured identically so any node can take over another node's work. The Manager / Dispatcher monitors cluster health and launches backup services as needed.
Disaster recovery
Active-active across a primary data center (DC) and a disaster recovery (DR) site, each running a complete stack.
| Resource | Replication mechanism |
|---|---|
| SQL database | Oracle Data Guard or equivalent — synchronous or asynchronous replication to the DR SQL instance |
| MinIO object store | Side-bucket replication — binary objects and images mirrored continuously to the DR MinIO cluster |
| Matcher cluster | Independent matcher instances run in the DR site; Ignite caches are populated from the replicated template store |
In active-active mode the DR site can independently serve enrollment and matching, providing zero-downtime availability if the primary site fails.
Cloud and virtualization
The platform can be deployed on virtualized infrastructure or private cloud; the database can be a cloud DB service or a managed cluster. Ensure network, storage, and replication characteristics match the deployment's performance and DR requirements.
See also
- Architecture Overview — service-level breakdown
- Biometric Functions — what the deployment hosts at runtime