Deployment Recommendations

There are different methods for obtaining the license for Digital Identity Service below and above version 1.20.0 of the project. To access additional information, please refer to our technical documentation for detailed license information.

To ensure the optimal performance and stability of Digital Identity Service and cache infrastructure, we strongly recommend to use a monitoring tool.

We have good experience with Prometheus for monitoring purposes and Apache JMeter, that we employed for our performance testing. However, the choice of monitoring and testing tools is ultimately up to you, based on your project’s specific requirements and preferences.

Upgrading the Digital Identity Service on live production may cause temporary cache inconsistencies. To avoid these issues, we strongly recommend scheduling a maintenance window for the upgrade.

The Digital Identity Service is recommended to be scaled horizontally. Multiple service instances can utilize either a shared cache or a cache cluster. If the DIS service is scaled horizontally, you can usually achieve higher throughput or lower latency if your server is overloaded.

The GPU image runs on the CPU until the GPU backends are switched on. The face models and the document models are configured separately:

The backend each model actually runs on is logged at start-up. We recommend enabling the model warm-up (available since version 1.70.0) on GPU instances, so that the first requests are not slowed down by model loading.

A GPU node is cost-efficient only for the work that runs on the GPU. Document processing does not get faster on a GPU node, so the most efficient deployment runs two node pools behind one Digital Identity Service address:

The client keeps calling a single URL. A layer 7 router (a service mesh, an ingress controller or a load balancer with path-based rules) sends each request to a pool by its URL path. This example rule matches the face calls. Everything else goes to the CPU pool:

The rule matches only the path segment right after the customer ID. /api/v1/customers/{id}/inspect goes to the GPU pool, while /api/v1/customers/{id}/document/inspect stays on the CPU pool.

Both pools must use the same cache. One onboarding moves between the pools: the documents are processed on the CPU pool and the selfie on the GPU pool, and both read the same customer record.

The following measurements were made on AWS in eu-central-1 for an onboarding with a selfie and passive liveness, a two-sided ID document, NFC reading and a trust evaluation:

From these measurements:

To size the pools for a target throughput:

A GPU-only deployment costs about the same as a CPU-only one, because the document work does not get faster on the GPU. Splitting the work between two pools lowers the compute cost of the Digital Identity Service by about 43 %.

For optimal performance, configure the expiration of records according to the nature of the implemented process:

Memory consumption for longer processes can be lowered by cleaning records once no longer needed. The API provides deletion methods for each resource.

Size the network bandwidth of the cache, not only its memory and CPU. Every Digital Identity Service call reads the whole customer record from the cache, including its images. An onboarding with a two-sided ID document and NFC transfers about 29 MB between the Digital Identity Service and the cache, so 6 onboardings per second need about 1.4 Gbit/s. Burstable cache instances can sustain such traffic only until their burst credits run out.

The Digital Identity Service supports Redis as a cache option in various setups which depend on the configuration of your environment. The Lettuce client is used for communication with Redis.

This cache option intended for development and test purposes only. Each instance of Digital Identity Service runs its own embedded EhCache, which is not shared between other instances. This means that running multiple Digital Identity Service instances in cluster mode will lead to unexpected behavior.

You can set the maximum memory size for the embedded cache through configuration properties. This includes options for both Java heap and off-heap memory. While Java heap memory is faster for I/O operations, it incurs a performance cost due to Java garbage collection. For the Digital Identity Service, this performance difference is expected to be negligible.

The Digital Identity Service running inside the container, built from Dockerfile, runs under dot-dis user and not as root user. This may cause issues with files and directories mounted from outside the docker container (e.g. logs directory). To overcome this issue, ensure that the user’s UID (User ID) on the host machine, who owns the file or directory, matches the UID of the dot-dis user, which is 1000.

Alternatively, you have the option to build the Docker container using the root-user.Dockerfile, which runs Digital Identity Service under the root user and does not have this limitation.

The JVM configuration can be customized using the JAVA_OPTS environment variable when running the Docker container. This can be useful when adjusting parameters like Java max heap memory size.

Example use:

To access additional information, please refer to docker section in our technical documentation.