Microservice Software for Collecting and Analyzing Data

About the client

The client is a startup that built the world's first odor perception platform. Built on a foundation of NASA-patented technology, it is designed to identify medical conditions through breath or body odor using a specialized sensor and AI.

About the project

The client reached out to Elinext with the need for a Node.JS developer, who would build new microservices and support existing ones.

When the Elinext developer joined the project, there was only one service in development, which was the Configuration service. It is the core microservice in the project, and every other microservice interacts with it to request configurations to work with routing. The same goes for physical devices that receive odor, as their functionality also depends on the Configuration microservice.

Among other microservices, which our developer has produced, are:

Notification service – it sends out notifications through Flutter messages, push notifications to iOS and Android devices, email, and WebSocket (Redis is used to distribute requests to the notification service); the service is used for notifications management and tracking.
Fleet management service – used for device management, where you can generate device numbers and add them to Thingsboard, a platform for sending requests to devices, turning them on/off, implementing an energy-saving regime, and other device-related actions.
OLAF Hub service – it is used for managing experiments and collecting data and protocols; this service works based on events and descriptions of the annotation service.
Annotation service – it is used to manage annotations and data labeling, including devices, services, and experiments. Annotations are equipped with events, which consist of instructions stored in a configuration specific to each annotation. Based on the triggered events, you can operate devices, terminate experiments, and perform other actions.
Commercial and Domestic Entities Service (CDE service) – used for segregating access between users and devices, such as trial periods, device sharing, marking of device working area, and others.

Some of the services communicate with each other using Kafka. Since the Configuration service is a loaded one and includes a cache, other services communicate with it through a library developed by Elinext. It works in a way, that first, the request is sent to Kafka to search for configuration in the cache. If the configuration is not found, the request then proceeds through gRPC. In case the request to gRPC encounters an error, the request is done through HTTPS. The most challenging service to work with was the Notification service. The issue arose when, under heavy load, multiple notifications could be sent simultaneously to a device. An Elinext developer implemented a solution that enhanced the service's performance, enabling it to handle multiple notifications at once.

Results

The Elinext developer has prepared a stable code that the client is currently testing. His extensive experience successfully addressed the issue of overloaded services, leading to an overall improvement in performance.