Services interaction

There are separate databases specified for each service in the images below. This is done for illustration purposes.

It is not required to launch several similar databases for each service. You can launch a single database instance (e. g., PostgreSQL) and use it to store data for all the LP services. Each service will have its own table in this database.

See "General concepts" for details about the databases used by LP services.

API service provides a RESTful interface for faces and bodies detection, extraction and matching procedures.

Requests are sent to LP via HTTP. A common case is when an external service sends requests to LP, receives results and processes the results according to business needs.

Services interaction

Some services can be disabled (see "General concepts").

API receives requests, processes them and checks user authorization using a request to the Accounts service (A0). The Accounts service checks if the user's credentials exist in the Accounts database (Acc1). If the user data is not found in the database, then an authorization error is issued. If the data is found, then the corresponding information is sent to the API service, where it passes the original requests to other services.

The main operations (detection, estimation, extraction, matching) are performed as described below.

Approach "Sequential performing of requests":

• The "detect faces" request, in which face detection is performed, face parameters are estimated and samples are created, is sent from the API service to the Handlers service (A1), and then redirected to Remote SDK service (H1).
• The "extract attributes" request, in which temporary attributes are extracted, is sent from the API service to the Handlers service (A1), and then redirected to the Remote SDK service (H1).
• The request "matching faces" is sent from the API service to the Python Matcher service (A6).

Approach "Parallel performing of requests":

• The "create handler" request with the rules for detecting, estimating, extracting and matching faces and bodies is sent from the API service to the Handlers service (A1).
• The "generate events" request is sent from the API service to the Handlers service (A1), and then redirected to the Remote SDK service (H1).

The API service sends requests to the Faces service to create/modify new faces (requests from the "faces" section), as well as create/modify lists (requests from the "lists") section (A2).

The API service receives information about the current license terms from the Licenses service (A3).

The API service sends samples from external services to the Image Store service (the "save face/body sample" request) (A5).

Handlers creates new handlers and stores them in the Handlers database (H2).

The service also redirects requests for detection and estimation to the Remote SDK (H1) service.

The Handlers service is enabled/disabled in the "ADDITIONAL_SERVICE_USAGE" setting.

Remote SDK processes face/body detection and attributes creation requests. It estimates face attributes and face/body parameters.

The Remote SDK service processes the request to detect faces/bodies and estimate parameters from the Handlers (H1) service, sends the result back to Handlers (H1), which sends the received samples to the Image Store service (H3).

The Remote SDK service processes the request to create attributes from the Handlers (H1) service by requesting existing samples from the Handlers service, which it requests from the Image Store service (H3). Next, the Handlers service sends the created temporary attributes to the Faces (H4) service, which saves them in the Redis database (F1).

Requests "/iso", "/sdk", "/liveness" are performed directly to the Remote SDK service (A9). In this case, the license is checked by interacting with the Licenses (RS1) service. To be able to use a set of samples, the Remote SDK service interacts with the Image Store (RS2) service.

Image Store receives samples from the Remote SDK service and stores them on a local storage or in S3-compatible cloud storage and provides access to them (Im1).

The Image Store service is enabled/disabled in the "ADDITIONAL_SERVICE_USAGE" setting.

Licenses. The Licenses service receives information about the number of created faces with attributes from the Faces database (Li1).

Faces is responsible for interaction with Faces database, which stores: faces, descriptors for faces, and lists (F2). It provides access to the stored data for API, Python Matcher, and Tasks services.

Faces also stores the created temporary attributes in the Redis database (F1).

Every time a new face is created, the Faces service sends information about the number of created faces with attached attributes to the Licenses service (F3) (see the "Faces limit" section).

Events  service stores and provides information about events (the Events section). After an event is created, the Events service receives the created event from the Handlers service (H6) and stores it in the Events database (Ev2).

The Events service is enabled/disabled in the "ADDITIONAL_SERVICE_USAGE" setting.

Python Matcher can receive matching requests directly from the API service (A6). If a matching policy is specified in the handler, then a request to match descriptors will come from the Handlers (H7) service. Python Matcher sends matching requests to the Faces database (M3) or Events database (M1). The databases matches descriptors and sends results back to the API service.

Python Matcher can also receive the temporary attributes required for matching from the Redis database (M2).

It is possible to additionally use the Python Matcher Proxy service, which can redirect requests to Python Matcher or matching plugins. Matching plugins can significantly speed up the matching requests execution (see the "Matching plugins" section). This service is not shown in the diagram, but has the same communication lines as the Python Matcher service.

Admin. A user can manage accounts and perform other actions via the user interface of the Admin service (Adm1). The corresponding requests are sent to the Admin service (Adm2).

The Admin service receives information about accounts from the Accounts (Adm3) service.

All information about user accounts is stored in the Accounts database (Acc1).

The Admin service sends requests to Tasks service (Adm4). These tasks are performed for LP databases in general, not for a single account ID.

The Admin service receives information about the current license terms from the Licenses service (Adm5).

The Admin service checks the current number of created faces with linked attributes in the Faces database (Adm6) and calculates the percentage of the database of fullness.

The Admin service performs requests to all LP services, receiving system information (see "/luna_sys_info" request) (Adm7).

Sender. All generated events are received by the Redis DB from the Handlers service (H5). External third-party party software subscribes to receive events according to the specified filters (Se2). Sender service checks Redis channel, receives the required information and sends it to external software (Se1).

The Sender service is enabled/disabled in the "ADDITIONAL_SERVICE_USAGE" setting.

Configurator. LP services receive configuration parameters from the Configurator service (Con1). A user can manage configurations in Configurator by means of the user interface (Con2). The changes are sent to Configurator (Con3). All the changes in configuration files are saved in Configurator DB (Con4).

Configurator is utilized for each Luna service by default.

Tasks. Tasks service receives requests from API service (A8). Then Tasks creates and stores a task in the Tasks database (T1).

Next, the Tasks service interacts with its worker via Redis (T2, T3), creating subtasks and merging the results. For more information, see "Task diagrams" section.

The Tasks service receives data from the Faces service for the Clustering, Linker and Additional extraction tasks (T4).

The Tasks service receives data from the Events service for the Clustering and Linker tasks (T9, T10).

The Tasks service receives data from the Handlers service for the Estimator task (T6).

The Tasks service is enabled/disabled in the "ADDITIONAL_SERVICE_USAGE" setting.

The interaction of Tasks workers with other services depends on the task type.

Tasks workers receive data from Faces service for every processed task (T5).

Tasks workers send a request to Python Matcher (T7) for clustering, cross-matching and ROC creation tasks.

Tasks workers store all the reports in the storage of Image Store (T8). Tasks workers also store and receive clusters from Image Store.

Tasks workers send the request for additional extraction task to the Handlers service (T6).

Monitoring. Monitoring system receives requests and errors from each service (Mon1). This data stores in the Influx database (Mon2). Then the monitoring data is sent to Grafana to visualize the monitoring data (Mon3). You can find more information about monitoring in the "Monitoring" section.

Grafana and InfluxDB services have their own interfaces (see the "User interfaces" section).

This diagram does not contain the architecture of Backport 3, Backport 4, Lambda services and video analytics services (Video Agent and Video Manager). See the detailed architecture of the Backport 3 service in "Backport 3 architecture" and the Backport 4 service in "Backport 4 architecture". See the Lambda service interaction diagram in "Lambda diagrams".