Service interaction

Below is a diagram of the interaction of the index module services.

Service Interaction

Before sending the matching request from the API service, the user must create an index, which is created by creating a task to build it. The task is created in the Index Manager service and can be one-time type or background type.

After creation, the task is sent to the queue in the Redis database (IMan1).

In addition to the queue, the Redis database acts as a repository for all index building tasks. It also uses the RedLock mechanism to ensure the operation of multiple instances of the Index Manager service (see the "Working with multiple instances" section).

The Index Manager service interacts with the Faces database (IMan2) to monitor changes in lists if the task of the background type has been created.

Next, the Index Manager sends a request to the Indexer service to build the index (In1). After receiving the request, the Indexer service extracts the descriptors from the Faces database (In2) and starts building the index. The built index is stored in storage (In3).

After successfully creating the index, the status of the task changes to "success". Before sending the matching request, you need to check the status of the index using the "get tasks" request to the Index Manager service. When sending user requests to the Index Manager service to get information about indexes, the service will interact with the index storage (IMan3).

The Indexed Matcher load the index into memory (IMat1), loads the matching label (contains the "list_id" of the loaded into memory index) into the Redis DB (IMat2) and listens to the Redis stream until the matching request appears there.

The Indexed Matcher service constantly monitors changes in face lists by interacting with the Faces (IMat4) database. If new changes are made to the list, the Indexed Matcher service gradually adds new descriptors to the corresponding index loaded into memory. In this case, the index located in the repository remains unchanged until it is rebuilt. If necessary, this functionality can be disabled (see section "Refreshing index in memory").

After the index is created and loaded into the memory of the Indexed Matcher service, the user performs the matching request in the API service, attaching an image of the reference. This request is redirected to the Python Matcher Proxy service (A1), where the matching plugin generates a request of a specific format containing the matching label and the descriptor of the reference, and determines whether the Indexed Matcher service loaded the matching label into the Redis database. Next, the service is selected to perform the matching: - if the matching label is not loaded into the Redis database, then the request is sent to the Python Matcher (PMP1). In this case, the matching will be performed using the classical brute-force matching descriptors. - if the matching label is loaded into the Redis database, then the request is sent as a message to the Redis stream. The Indexed Matcher service reads a message from the Redis stream (IMat2). After that, the Indexed Matcher service checks the presence of a LUNA PLATFORM 5 license for the possibility of performing the matching, interacting with the Licenses (IMat3) service.

See "Matching plugin for Python Matcher Proxy" for details on choosing a service to perform the matching.

After the matching is completed, the Indexed Matcher service writes the matching results to the Redis channel (IMat2). The Python Matcher Proxy service matching plugin reads the matching results and returns them to the user in the API service (PMP2).

See the "Sequence diagrams" section for a more detailed description of the LUNA Index Module processes.