Designing a Scalable YOLO-Based Decision Support Framework for Mitochondrial Analysis in EM Imaging

Abstract

This study presents a scalable decision support system (DSS) framework designed to meet the growing demands of instant data-driven decision-making environments. The architecture integrates key technologies, including Apache Kafka for parallel data streaming, a Python-based data analytics module for distributed processing, JWT-based secure user authentication, and WebSocket communication for instantaneous prediction delivery. The system performs mitochondrial localization in electron microscopy (EM) images using multiple versions of the YOLO (You Only Look Once) object detection model. The publicly available CA1 Hippocampus dataset was used for detection evaluation. Among the evaluated models, YOLOv10x achieved the highest detection performance, yielding a mean average precision (mAP) score of 95.2%. Experimental evaluations of the DSS were conducted under simulated load conditions using the Artillery tool to assess the system’s scalability and responsiveness. Empirical results indicate consistent low-latency performance across varying consumer group sizes, confirming the architecture’s ability to scale the analytics module horizontally without compromising responsiveness. These findings validate the system’s suitability for just-in-time decision support applications. In particular, the system may support clinicians in the task of mitochondrial analysis, where structural abnormalities can be indicative of pathological conditions, including cancer. By enabling early detection of such abnormalities, the proposed framework has the potential to contribute to the timely diagnosis of diseases such as cancer. The proposed study differs from existing studies by combining deep learning with real-time scalable data processing technologies, such as Kafka and WebSocket, in a web-based DSS application for mitochondria detection.

1. Introduction

Decision support systems have increasingly evolved into intelligent, real-time platforms capable of assisting decision-making processes across a range of domains [1,2,3,4,5]. As datasets become larger and more dynamic, DSS frameworks must incorporate real-time data processing, concurrent computation, and robust delivery mechanisms. This study presents a scalable decision support system developed as a web-based application. It integrates modern components to support the mitochondria localization task.

Mitochondria produce the energy required for cellular metabolic activities. Abnormal numbers or shapes of mitochondria are associated with cancer and other metabolic disorders [6,7,8,9,10]. Detecting such differences early may help enable early cancer diagnosis. Although mitochondria images can be obtained using techniques such as electron microscopy, manually counting them is difficult. Because each cell contains many mitochondria and the human body contains many cells, developing fast and automated tools to assist experts in detecting and counting mitochondria can be highly beneficial.

This study presents a comprehensive DSS framework designed to automate mitochondria detection and counting from electron microscopy images using YOLOv10 and YOLO26 variants. The system is low-cost, and it produces objective and countable results. Thus, it can be beneficial to assist experts in detecting and counting mitochondria. This study makes the following contribution to the literature:

(I) Assists early detection of some disease: Counts and shapes of mitochondria can be critical biomarkers for early detection of cancer and metabolic disorders. The system reduces the dependency on manual labeling and accelerates diagnosis by using YOLOv10 and YOLO26.

(II) Integrates SOTA technologies for mitochondria detection: Integration of Apache Kafka, WebSocket, YOLOv10, and YOLO26 for mitochondria detection contributes to both medical and computer science literature.

The remainder of the paper is organized as follows. Section 2 reviews relevant literature on mitochondrial image analysis and scalable architecture-based studies. Section 3 details the methodology, including system design, YOLOv10 integration, and Kafka-based streaming mechanisms. Section 4 presents the experimental setup and performance evaluation, with a focus on detection accuracy and latency under varying computational loads. It also discusses the implications of the results and potential deployment considerations. The paper is concluded with Section 5 providing final remarks.

2. Related Works

2.1. Scalable Architectures for Instant Data Processing

Recently, technological advances in cameras, sensors, microscopes, and other medical equipment have enabled data collection. Processing of large amounts of data is also possible using powerful hardware. To handle this data efficiently and support real-time applications for multiple users, scalable systems are being developed in many fields. Although the literature is extensive, this section highlights a few representative studies with different architectural approaches.

In [11], the authors proposed a scalable architecture that enables spoken dialogue systems to run on the web. Scalable architectures are also widely used in healthcare. For example, ref. [12] presented an architecture that allows multiple clinical decision support systems (CDSSs) to operate on a common telemonitoring platform without interfering with each other. Similarly, ref. [13] proposed a scalable system combining Twitter, Kafka, Spark, and Cassandra to predict diseases from medical data streams. In that study, the best accuracy was achieved with the Random Forest algorithm after feature selection using the Relief algorithm. Additionally, ref. [14] introduced a scalable e-health architecture that enables clinical devices to communicate automatically via the internet, improving diagnostic speed and accuracy. Ref. [15] presented Personal Health Dashboard (PHD) software that provides scalability for analyzing large biomedical data. This software can store and analyze complex data such as wearable devices, health records, and genetic data. In [16], the authors developed a scalable and intuitive deep learning toolkit called R2D2. R2D2 is focused on semantic segmentation tasks for medical imaging.

2.2. Automated Mitochondria Analysis

Owing to technological development, high-performance medical image analysis studies have been conducted in recent years [17,18,19,20,21,22]. In classical machine learning, the feature extraction step needs expert knowledge. Recently, owing to deep learning approaches, the feature extraction step is automatically applied. Thus, deep learning makes it possible to carry out more effective image analysis.

The literature includes some mitochondrial analysis studies, including those focusing on mitochondria segmentation [23,24,25]. In [26], the authors applied supervoxel-based segmentation. This method combines shape features that can describe the 3D shape of the mitochondria. In [27], the authors proposed a method that uses shape information and regional statistics to segment mitochondria in EM images. The algebraic curves and regional information were used to segment the mitochondria at the predicted locations. In [28], a pixel-based approach was developed to analyze mitochondrial movements to examine abnormalities of mitochondria under conditions of cell stress, swelling, etc. In [29], the authors focused on the segmentation of mitochondria using a CNN. Ref. [30] shows high-performance results using pixel-wise segmentation; it operates within a semantic segmentation framework. Also, in [31], a novel recurrent neural network (RNN) was proposed for the mitochondria segmentation task. Moreover, [32] presented MitoSegNet, a software tool that combines segmentation and morphological analysis functions and can run on Windows and Linux systems. Unlike these studies, the system proposed in this paper formulates mitochondria detection as an object detection problem. This brings several practical advantages. This approach enables faster inference and direct quantification of mitochondria as discrete objects. This is particularly beneficial in studies where mitochondrial count, morphology, and spatial distribution are crucial biomarkers.

Some of the previous studies aimed to segment mitochondrial compartments. In [33], a CNN-based system was developed to discriminate four different mitochondrial compartments (matrix, outer, inner, and intermembrane regions). In [34], a system that localizes mitochondrial subdivisions was developed. A bidirectional LSTM with a self-attention mechanism was used in the study.

Also, various studies have focused on mitochondria detection [35]. For example, ref. [36] utilized classical image processing methods such as ellipse detection for mitochondria detection. However, this approach has drawbacks, such as susceptibility to noise and the need for manual intervention. Ref. [37] used the Faster R-CNN algorithm for mitochondria detection in ATUM-SEM images. In [38], using cryo-electron tomography (cryo-ET)-based images, Faster-RCNN was used to detect mitochondria. Faster R-CNN is a relatively heavier detection model and limits real-time usability, especially when processing large-scale EM datasets. In contrast, the proposed YOLO-based system is optimized for real-time, low-latency inference and supports large-scale image processing through Kafka-based data pipelines. Moreover, unlike previous mitochondria analysis studies, by employing Apache Kafka for parallel message processing and WebSocket for asynchronous communication, the proposed architecture enables efficient, scalable, and just-in-time image analysis.

2.3. YOLO and Transformer-Based Approaches for Medical Imaging

YOLO and Transformer-based approaches are widely used for medical imaging tasks in the literature. In [39], a modified YOLOv8 model was used to accurately detect tumors within MRI images. The model performed better than the original YOLOv8 model and also performed better than other object detectors (Faster R-CNN, Mask R-CNN, YOLO, YOLOv3, YOLOv4, YOLOv5, SSD, RetinaNet, EfficientDet, and DETR). Ref. [40] proposed a two-stage deep learning model integrating U-Net, YOLOv8s, and the Swin transformer to detect lung cancer nodules in computer tomography images. The model demonstrates high accuracy and a reduced false positive rate. Ref. [41] proposed TransUNet, which merges Transformers and U-Net, as a strong alternative for medical image segmentation. TransUNet shows high performance on different medical applications, such as multi-organ segmentation and cardiac segmentation. Ref. [42] used a YOLOv7-based model for kidney detection in medical images. The results show that the model achieves high accuracy, sensitivity, and mean average precision (mAP) values in kidney and tumor detection.

3. Materials and Methods

3.1. Decision Support System Overview

At the core of the system lies a Kafka-based distributed event-streaming backbone, enabling high-throughput and low-latency communication across components. User inputs, submitted via the web interface, are processed in parallel by the Python-based analytics module, ensuring scalability and resilience under varying loads. Figure 1 illustrates the system architecture, including producers, parallel consumers, communication servers, and the persistent storage layer. Predictions are instantly returned to the client interface via WebSocket for an interactive user experience. Access control is enforced through JWT-based authentication and role-based mechanisms, with users, roles, and operational logs persistently stored in a PostgreSQL database.

3.2. Web Application and User Interfaces

The web application serves as the primary user interaction point within the proposed DSS framework. Designed with an emphasis on usability and responsiveness, the interface facilitates seamless data entry, model interaction, and real-time visualization of predictions. Upon successful authentication, users assigned with administrator privileges are automatically directed to the dashboard page, which consolidates system functionalities into an accessible and intuitive environment.

The dashboard and model interaction interface are illustrated in Figure 2. This environment enables authorized users to upload mitochondria microscopy images, which are subsequently analyzed using a deployed YOLO-based object detection model. Upon submission, the image data is serialized and transmitted through the Apache Kafka messaging infrastructure, facilitating efficient distribution to parallel data analytics consumers for just-in-time processing.

Once the object detection algorithm processes the image and successfully localizes the mitochondria, the resulting annotations are published to a designated Kafka topic configured for output communication. This asynchronous yet efficient communication mechanism enables downstream components to consume the detection results independently. To support seamless and low-latency feedback to the user interface, the system employs a WebSocket server that listens to this output stream. As a result, the detected locations are immediately sent to the web-based dashboard. This allows users to visualize the predicted regions on the original image almost in real time without manually refreshing the page.

3.3. Data Streaming and Analytics

Efficient and reliable data streaming is a critical requirement for modern DSS designed for instant analytical response. In the proposed architecture, Apache Kafka acts as the backbone for data transfer between system components. It enables high-throughput and low-latency communication across distributed modules. Apache Kafka is a distributed event-streaming platform specifically designed to handle large volumes of data with minimal delay. Its scalable architecture allows data to be streamed continuously from producers to consumers. It ensures that the system remains responsive even under increasing workloads.

In the proposed DSS framework, microscopy images uploaded via the web interface are published to designated Kafka topics. The data analytics module, designed around Kafka’s consumer group architecture, subscribes to designated topics and retrieves image data for parallel processing. This configuration enables efficient workload distribution and supports instant detection and quantification of mitochondria using a YOLO-based model. As shown in Figure A1, the analytics pipeline is implemented using a Python-based Kafka consumer. It listens for base64-encoded image data, decodes and processes the images with a preloaded YOLO model, and sends the annotated results to an output Kafka topic. The figure illustrates key components of this loop. It includes consumer initialization, instant image parsing, YOLO inference execution, and the serialization of detection results for downstream use. The system runs multiple instances of the consumer using the same group.id parameter (line 31). Through Kafka’s partition-aware consumer group mechanism, incoming messages are distributed across independent processing units, enabling parallel processing. This implementation demonstrates the system’s practical realization of streaming analytics within a scalable, event-driven architecture.

To achieve effective parallelism and load balancing, Kafka topics are divided into multiple partitions. Each partition acts as a sequential, ordered log that can be consumed independently. Kafka organizes data into multiple partitions. This allows multiple consumers to read from different partitions simultaneously, improving the system’s throughput and responsiveness. As described in [43], partitioning plays a key role in scaling data pipelines for high throughput and fault tolerance. Consumer groups are a fundamental concept in Kafka’s design for distributed processing. A consumer group is a collection of consumers that work together to consume data from a topic in a coordinated manner. It ensures that each partition is read by only one consumer within the group. This mechanism allows the system to scale horizontally: as the number of consumer instances increases, more data can be processed in parallel, improving overall performance. Figure 1 illustrates how consumer groups are utilized in the data analytics pipeline to manage the parallel processing of incoming data streams. A critical design consideration for maximizing parallelism is ensuring that the number of partitions is greater than or equal to the number of consumers in a consumer group. When properly configured, this arrangement allows each consumer to be assigned a dedicated partition. It prevents bottlenecks and enables true parallel data processing. Conversely, if there are more consumers than partitions, some consumers will remain idle, limiting the system’s scalability. The proposed DSS architecture leverages Kafka’s topic partitioning and consumer group features. In addition, it integrates a data analytics module for predictive analysis. This design allows the system to efficiently handle real-time data streams and supports scalable, distributed decision-making and near real-time analytics. To validate the real-world applicability of the proposed DSS architecture, the application was deployed onto a dedicated server environment. This deployment allowed end-to-end testing of all components, including the web application, Apache Kafka services, the data analytics module, and the PostgreSQL database.

3.4. YOLOv10 Model for Mitochondria Detection

YOLO is a very popular object detection algorithm owing to its performance [44,45,46,47,48,49,50,51,52,53]. Over time, different YOLO versions have been created by researchers. The YOLOv10 version [54] was developed in May 2024. Based on [54], YOLOv10 improves both efficiency and accuracy in object detection compared to previous YOLO versions. In previous versions, dependency on NMS and architectural inadequacies prevented optimal performance. In the YOLOv10 version, training is provided without NMS. Also, the dual label assignments feature is added to the architecture. They incorporated another one-to-one head for YOLO. During training, these heads are optimized with the model. During inference, they discard the one-to-many head and make predictions using the one-to-one head. It is designed with various model scales to meet different application needs. YOLOv10n is recommended for very limited resources. YOLOv10s is a smaller version that optimizes speed and accuracy. For general-purpose uses, the mid-sized YOLOv10m model is recommended. The YOLOv10b version has an increased width for higher accuracy. The major version, YOLOv10l, is designed for higher accuracy at the cost of increased computational resources. The extra-large version, YOLOv10x, is developed for maximum accuracy. In [54], YOLOv10 was tested on well-known datasets such as COCO and showed superior performance and efficiency. It showed significant improvements in latency and accuracy compared to its previous versions. With this motivation, in this study, YOLOv10 models at different scales were trained and tested for the task of detecting mitochondria. Models of different scales were compared. Thus, the regions containing mitochondria were included in the bounding box, and their locations were determined.

Unlike natural datasets, electron microscope images contain low-contrast, grayscale structures and small mitochondria, making them challenging to detect with YOLOv10. Selecting the most appropriate parameters is crucial to overcoming this challenge. Therefore, the YOLO model that produced the best results was trained and tested with various parameters. These results are also presented in the Experimental Results Section.

3.5. YOLO26 Model for Mitochondria Detection

YOLO26 [55], the latest version released on 14 January 2026 by Ultralytics, is designed from the ground up for edge devices and low-power devices. It eliminates unnecessary complexity and offers a simplified design that is faster, lighter, and more accessible.

NMS, pioneered in YOLOv10, was further developed in YOLO26. Thus, this post-processing step was eliminated, and a faster and lighter model was produced. It uses the MuSGD optimizer, a hybrid of SGD and Muon. This optimizer brings enhanced stability and faster convergence.

The Distribution Focal Loss (DFL) module, included in previous versions, had complicated export and limited hardware compatibility. This module was removed in YOLO26, thus simplifying inference and increasing support for edge and low-power devices. Owing to its improved loss functions, it increases detection accuracy in the field of small object recognition.

Similar to YOLOv10, YOLO26 has five subversions for detection. All of these subversions were trained for mitochondria detection, and their results were compared.

4. Experimental Results

4.1. Dataset and Data Preparation

In this study, the CA1 Hippocampus dataset [56,57] was used. This public dataset includes two volumes of EM images of mouse brains. Each volume consists of 165 slices, each with a resolution of 1024 × 768 pixels and a voxel size of 5 × 5 × 5 μ. Each image has corresponding two-class (background and mitochondria) ground truth volumes, as shown in Figure 3. In this study, the goal is the detection and localization of mitochondria. Therefore, the ground truths prepared for segmentation could not be used directly. Instead, the location of each mitochondrion in the training and test sets was labeled with a bounding box using Roboflow [58]. For each image, an original image was submitted to the annotation tool while the corresponding ground truth segmentation mask was viewed alongside. Using the mask as a reference, to locate each mitochondria, bounding boxes were manually drawn on the original image in the annotation tool.

In order to increase the amount of data, some data augmentation approaches were applied. These are given in

Table 1. Data augmentation processes.

Technique	Description
Flipping	Horizontal and Vertical
Rotation	Between −15 and +15 degrees
Shearing	+/−10 degrees (Vertical and Horizontal)

. Data augmentation was applied by randomly selecting images from the training set and performing random transformations such as flips, rotations, and shear operations, as seen in the table. The augmented dataset included the original images as well, resulting in a threefold increase in size. The training set initially consisted of 165 images and was expanded to 495 images through data augmentation. After the annotation and data augmentation process, the annotated mitochondria number was 7269 in the training set and 2558 in the test set.

4.2. Comparative Results of Detection

In this study, experiments were performed on different YOLOv10 and YOLO26 versions, and their results were compared. The used parameters on the versions are reported in

Table 2. Training parameters.

Parameter	Value
Optimizer	AdamW
Learning Rate	0.002
Momentum	0.9
Decay	0.0005
Image Size	640 × 640

. The training parameters listed in this table were selected based on the official YOLOv10 and YOLO26 implementations and established practices in object detection. The Adam optimizer was chosen due to its effectiveness in stabilizing training for modern YOLO architectures [59]. A learning rate of 0.002, momentum of 0.9, and weight decay of 0.0005 are commonly adopted in recent YOLO variants and have demonstrated robust convergence behavior [54]. An input image size of 640 × 640 was used, which is a standard resolution in YOLO-based models to balance accuracy and computational efficiency [60]. The same training parameters were consistently applied across all YOLOv10 and YOLO26 variants (from n to x) to ensure a fair comparison. This allows us to isolate the impact of model architecture and scale on performance without confounding effects from varying hyperparameters.

In the literature, object detection systems are usually evaluated using the mean average precision (mAP) metric. Thus, in this study, the evaluation was applied using the mean average precision metric (Equation (4)). Also, the inference times of the models were compared.

$$\begin{array}{cc}\hfill AP& =\sum {\displaystyle \frac{\mathrm{precision}}{\mathrm{recall}}}\hfill \end{array}$$

(1)

$$\begin{array}{cc}\hfill \mathrm{Precision}& ={\displaystyle \frac{TP}{TP+FP}}\hfill \end{array}$$

(2)

$$\begin{array}{cc}\hfill \mathrm{Recall}& ={\displaystyle \frac{TP}{TP+FN}}\hfill \end{array}$$

(3)

where TP is true positives, FP is false positives, FN is false negatives, and AP is average precision. The mean average precision (mAP) is provided in Equation (4).

$$mAP={\displaystyle \frac{1}{N}}\sum _{i=1}^{N}A{P}_i$$

(4)

where N is the class number. For evaluation, the PyTorch package was used. The codebase was built with Ultralytics [54], and the comparative results of the YOLOv10 and YOLO26 versions are given in

Table 3. System performance comparison.

Model	Epoch Number	Training Time (hours)	mAP	Inference Time (ms)
YOLOv10m	146	1.386	0.923	19.5
YOLOv10b	146	1.431	0.930	24.7
YOLOv10n	198	0.875	0.934	3.8
YOLOv10s	200	1.342	0.944	8.6
YOLOv10l	200	2.810	0.945	32.7
YOLOv10x	143	2.354	0.952	48.5
YOLO26n	52	0.209	0.925	2.8
YOLO26s	60	0.253	0.945	8.2
YOLO26l	68	0.561	0.948	24.6
YOLO26x	85	1.535	0.949	48.5
YOLO26m	58	0.390	0.951	21.3

. All the training operations were started for 200 epochs. It was set to “stop training if no recovery for 10 epochs”. Based on this, the networks were finalized in different epoch numbers. These are reported in Table 3. As can be seen, the best mAP was obtained using YOLOv10x. This is an expected result, considering that YOLOv10x was developed to achieve a maximum success rate. On the other hand, in terms of time, the best performance was obtained with YOLOv26n. This is also an expected result, considering that nano versions were developed to achieve maximum speed. As seen, YOLOv10x and YOLO26x took longer inference times compared to other models. Experiments showed that YOLO26’s various versions consistently showed high and stable performance rates (mAP scores), and training was completed in a shorter time. Although YOLOv10x achieved the highest result in this study, this finding highlights YOLO26 as a stable and robust model.

After identifying YOLOv10x as the best-performing model in terms of mAP, additional re-training experiments were conducted by varying the optimizer, learning rate, and cosine scheduling parameters. As shown in the

Table 4. Re-training experiments with the best-performing model (YOLOv10x) under different hyperparameter settings.

Experiment	Optimizer	Learning Rate	cos_lr	mAP
1	AdamW	0.002	False	0.952
2	AdamW	0.002	True	0.939
3	AdamW	0.0015	False	0.942
4	SGD	0.01	True	0.952
5	SGD	0.002	False	0.948
6	SGD	0.001	False	0.950

, the highest mAP values were achieved with AdamW (lr = 0.002, cos-lr = false) and SGD (lr = 0.01, cos-lr = true) configurations. Nevertheless, other parameter settings also produced comparable results, indicating that the model demonstrates stable performance across different hyperparameter choices.

Figure 4 visualizes some sample test results of the YOLOv10x model. Figure 4a shows actual mitochondria labels in a bounding box and Figure 4b. shows predictions of the corresponding sample. In the figure, both the ground-truth labels and the model predictions are clearly distinguishable. Furthermore, careful examination of the predictions reveals that a structure located in the lower-left region of the image is classified as mitochondria despite the absence of a corresponding ground-truth label. This instance represents a false positive prediction and illustrates one type of error made by the system.

To assess the computational complexity of the YOLOv10 and YOLO26 variants, we analyzed two key metrics: the number of model parameters and the floating-point operations per second (FLOPs). The number of parameters reflects the model’s capacity and memory footprint, directly influencing training time and storage requirements. Higher parameter counts typically lead to larger models that require more computational resources but may achieve better accuracy. FLOPs, on the other hand, measure the computational cost during inference, indicating how efficiently a model can process input data in real-time. As shown in

Table 5. Comparison of the number of parameters and computational load (FLOPs) of different models.

Model	#Parameters	FLOPs
YOLOv10n	2,694,806	8.2 GFLOPs
YOLOv10s	8,035,734	24.4 GFLOPs
YOLOv10m	16,451,542	63.4 GFLOPs
YOLOv10b	20,412,694	97.9 GFLOPs
YOLOv10l	25,717,910	126.3 GFLOPs
YOLOv10x	31,586,006	169.8 GFLOPs
YOLO26n	2,375,031	5.2 GFLOPs
YOLO26s	9,465,567	20.5 GFLOPs
YOLO26m	20,350,223	67.8 GFLOPs
YOLO26l	24,746,511	86.1 GFLOPs
YOLO26x	55,634,703	193.4 GFLOPs

, the model size increases significantly from YOLOv10n (2.65M parameters) to YOLOv10x (31.58M parameters), with corresponding FLOPs rising from 8.2 GFLOPs to 169.8 GFLOPs. This trend demonstrates a clear trade-off between model performance and computational efficiency: while larger models like YOLOv10x offer higher accuracy, they demand substantially more hardware resources, making them less suitable for edge devices. In contrast, smaller models such as YOLOv10n are highly efficient and ideal for real-time applications with limited computational power. A similar trend can be observed among the YOLO26 variants.

4.3. Evaluation of DSS Architecture Performance

To evaluate the performance of the proposed DSS architecture, a series of load and stress testing experiments was conducted using the Artillery testing tool [61]. The main objective was to assess the system’s responsiveness and scalability under simulated real-world conditions, with particular focus on its ability to handle increasing data loads efficiently. The experimental environment was set up on a virtual private server (VPS) machine with an AMD EPYC 7543P processor, 4 cores, and 16 GB of memory, running on Ubuntu 22.04. The Apache Kafka cluster for data streaming was configured to use the KRaft (Kafka Raft) mode in Apache Kafka version 4.0.0. In this setup, the Kafka broker and controller operated within the same KRaft-based process and were executed locally on the same machine as the web application, data analytics modules, and supporting services. This configuration ensures that the observed performance reflects the capabilities of the proposed architecture, without network-induced variability.

In the testing setup, simulated image traffic was directed to the route responsible for sending images to the Apache Kafka cluster. Each virtual user submitted a sample image to the backend for just-in-time prediction by the data analytics module. The load profile was configured to simulate a constant arrival rate of 1 request per second over 60 s. Three distinct scenarios were evaluated:

• Scenario 1: A single consumer instance running within the data analytics module, responsible for processing all incoming prediction requests.
• Scenario 2: Two consumer instances operating within the same consumer group, enabling parallel processing of incoming data streams. To fully utilize all consumers, the Kafka topic was configured with three partitions to ensure each consumer could be assigned a separate partition and work independently for maximum throughput.
• Scenario 3: Three consumer instances operating within the same consumer group, enabling parallel processing of incoming data streams. Similar to Scenario 2, the Kafka topic was configured with five partitions so that each consumer could be assigned a separate partition and work independently for maximum throughput.

Following the experiments, key latency metrics were collected, including the mean, median, P95, and P99 response times. Mean latency represents the average time taken to process a request across the entire test duration. Median latency is the middle value of all recorded latencies, providing a measure less sensitive to outliers than the mean. P95 latency (95th percentile) represents the maximum latency experienced by 95% of requests, providing insights into typical worst-case performance under load. P99 latency (99th percentile) reflects the latency experienced by 99% of the requests, highlighting extreme outliers and rare delay events. These latency metrics are particularly important in instant decision support environments, where a consistent, low-latency response is critical. While mean and median values provide a general understanding of system behavior, P95 and P99 values reveal how the system performs under stress. It helps to uncover potential bottlenecks that might affect user experience during peak loads.

The detailed experimental outcomes, including graphical representations of the mean, median, P95, and P99 latencies for all scenarios, are presented in

Table 6. Comparative metrics obtained for all of the scenarios for 60 s.

Metric	1 Consumer	3 Consumers	5 Consumers
Mean Latency (ms)	763.3	703.9	708.4
Median Latency (ms)	713.5	685.5	699.4
P95 Latency (ms)	871.5	804.5	788.5
P99 Latency (ms)	1790.4	889.1	907
Request Rate (req/s)	1/s	1/s	1/s
Total Requests	60	60	60
HTTP 200 Codes	60	60	60
Downloaded Bytes	4020	4020	4020

and Figure 5, respectively.

The performance metrics gathered during the load testing phase reveal a stable system under increasing analytical load. Specifically, latency metrics—mean, median, P95, and P99—remain relatively consistent across tests involving 1, 2, and 3 Kafka consumers. This consistency is expected because all services were deployed on the same server. In addition, the workload of one request per second is low enough for a single consumer to handle without causing queuing or resource contention.

To further validate the scalability characteristics of the proposed architecture, a stress-testing phase was conducted under an enhanced computational configuration. In contrast to the initial single-node CPU-based deployment, two additional GPU-enabled cloud instances were provisioned using Google Colab. Each consumer instance was assigned to a dedicated GPU-backed execution environment. This modification isolates computational scaling effects by alleviating the CPU bottleneck identified in the earlier experiments.

The workload was prepared to ensure a controlled backlog-driven evaluation. Prior to each experiment, relevant Kafka topics were cleared, and all consumers were deactivated to prevent premature message processing. Subsequently, a fixed workload of 3000 requests was generated using Artillery, allowing the consumer group lag to reach its maximum level. Once the backlog was established, consumers were activated, and throughput was measured during the catch-up phase using the Kafka performance tool (kafka-consumer-perf-test.sh). The peak throughput was determined from the maximum observed message processing rate (messages/s). This procedure was repeated for configurations with 1, 2, and 3 consumers. Due to the computational characteristics of the YOLO-based inference, where each consumer internally spawns multiple worker processes and heavily utilizes CPU/GPU resources, each consumer instance was deployed on a separate server to avoid resource contention and ensure fair scalability assessment.

For performance testing, the consumer polling interval was reduced to 0.5 s (consumer.poll(0.5)) to enable faster message retrieval and minimize idle waiting time. To ensure that the benchmark strictly measures the computational latency of the YOLO-based inference engine and the horizontal scalability of the Kafka consumer group, the output payload was deliberately minimized. Instead of transmitting the annotated output images with detected abnormal mitochondria, the system returns only a lightweight response (e.g., requestId). This eliminates external factors such as network serialization overhead and I/O saturation that could otherwise distort the results. Such a design is consistent with real-world practices, where processed images are stored in cloud-based object storage systems, and only a reference URI is returned to the client.

Under this configuration, peak throughput was measured during backlog-drain conditions, thereby capturing the maximum sustainable processing rate of the consumer group. The observed results are depicted in Figure 6.

The results demonstrate a clear superlinear improvement from one to two consumers, followed by continued near-linear scaling from two to three consumers. The increase from 1.53 to 6.09 requests per second indicates that the single-consumer setup was previously limited by computational constraints. These limitations were mainly due to GPU inference throughput and resource contention. Distributing inference workloads across independent GPU-backed instances significantly increased parallel processing capacity. This reduced the processing latency per request and improved overall throughput.

The progression from two to three consumers (6.09 to 11.58 req/s) further confirms the horizontal scalability of the Kafka-based analytical pipeline. The absence of throughput saturation within this range indicates that neither the messaging layer nor the broker became the dominant bottleneck under the tested workload. Instead, system capacity scaled proportionally with the addition of computational resources.

From a scalability validation perspective, these findings confirm that the architecture exhibits effective horizontal scaling when computational resources are provisioned appropriately. To further examine whether horizontal scaling also translates into latency improvements, an additional experiment was conducted under a higher and sustained workload. In this phase, all analytical consumers were deployed exclusively on GPU-enabled Colab servers to eliminate CPU-related bottlenecks and to ensure that inference execution constituted the dominant processing component. This configuration enables a fair comparison by isolating the impact of consumer parallelism without interference from heterogeneous hardware constraints.

The workload was increased to a constant rate of three requests per second. This placed the system under significantly higher utilization. Under this elevated load, measurable reductions in latency were observed when the number of consumers was increased from one to two, as illustrated in Figure 7.

The reduction in mean latency from 770.4 ms to 580.6 ms, along with consistent improvements in median and tail latency metrics, confirms that distributing inference workloads across multiple GPU-backed consumers reduces processing contention and queuing delay. Since the request rate was held constant across both configurations, the observed latency improvements can be directly attributed to the increased parallel processing capacity rather than differences in workload intensity.

Equally important, the total number of requests completed (180) and the number of successful HTTP 200 responses (180) remained identical across both configurations. This result confirms that the system maintained complete processing reliability under increased load, with no failed or dropped requests. The absence of HTTP errors or timeouts demonstrates that the Kafka-based messaging layer, the distributed consumer group, and the web service integration operated in a stable and fault-free manner during the experiment.

These findings provide strong empirical evidence that horizontal scaling of GPU-backed consumers improves latency while preserving full processing correctness and system stability. The simultaneous reduction in latency and preservation of a 100% success rate confirms that the proposed architecture achieves both performance scalability and operational robustness under increased analytical load.

4.4. Discussion

The results demonstrated that the system can perform accurate mitochondria detection with low latency. The findings make it suitable for real-time applications in both research and clinical environments.

From an overall system perspective, these model-level performance characteristics are complemented by the scalability and reliability of the distributed inference infrastructure. The latency reduction observed when increasing the number of GPU-backed consumers was achieved without compromising system reliability or correctness. Under a constant request rate of 3 req/s, both configurations successfully processed all 180 requests, with 100% HTTP 200 response codes and no observed failures or timeouts. This confirms that the latency improvement results directly from enhanced parallel processing capacity and reduced queuing delay, rather than variations in workload or selective request handling. Overall, these results show that the proposed DSS achieves high detection accuracy and fast inference at the model level. It also maintains low-latency, reliable, and scalable performance at the system level. This makes it suitable for real-time deployment in practical biomedical analysis environments.

Despite the demonstrated scalability and low-latency performance, the current study also has several infrastructure-related limitations. First, the experiments were conducted using a single-node Kafka deployment, which may not fully reflect performance behavior in multi-node or geographically distributed clusters. Extending the system to such environments could introduce network latency, partition reassignment overhead, and additional fault-tolerance considerations. Second, while GPU-backed consumers improved throughput and latency, real clinical deployment may present challenges such as heterogeneous hardware availability, integration with hospital information systems, and handling high volumes of diverse EM datasets.

Addressing these limitations will help validate the proposed DSS under realistic operational conditions and guide optimizations for production deployment.

Ethical implications of AI-driven clinical support are also important in this type of study. Using clinical data in AI systems can pose risks to patient privacy and data security. The dataset used in this study contains no personal data. Imbalances in the training data can cause the model to produce erroneous or biased results for specific patient groups. To prevent this, the dataset was used for both training and testing, as originally provided. Ethical and transparent use is crucial for doctors to trust the system and adopt it in clinical practice. Collaborative work in this area is our future goal.

In summary, the proposed system addresses key gaps in the literature by proposing a high-performance, real-time tool for mitochondria detection. It also contributes a scalable system architecture that can be generalized to broader applications in medical sciences.

In this paper, experimental studies were performed on YOLO-based models. However, the system is suitable for extension to different object detection architectures. In particular, it is possible to integrate models such as Faster R-CNN [62], which uses two-stage detectors, and RetinaNet [63], which adopts a dense prediction approach. However, certain adaptations may be necessary considering the different computational costs of these models. For example, region-recommendation-based models like Faster R-CNN may generate higher inference times and affect real-time performance. In future studies, a comparative evaluation of the proposed method with different detectors will more clearly reveal the generalizability of the approach under different model architectures.

5. Conclusions

This study presents a DSS using mitochondria detection. For the system, YOLOv10 and YOLO26 models were used for detection. Different versions of the YOLOv10 and YOLO26 models were trained and tested for mitochondria detection, and their results were compared. The YOLOv10x model, which was developed to obtain a higher success rate, showed the best performance with a 0.952 mAP score. The smallest inference time was obtained at 2.8 ms with the YOLO26n version. This is a small version developed for faster analysis.

By structuring Kafka topics with multiple partitions and organizing analytics services into consumer groups, the system demonstrates the capacity for horizontal scaling, ensuring stable performance under increasing analytical demand. This scalability was confirmed through throughput and latency measurements in GPU-backed deployments. Peak throughput increased from 1.53 requests per second with a single consumer to 11.58 requests per second with three consumers. Meanwhile, mean latency decreased from 770.4 ms to 580.6 ms when scaling from one to two consumers under a constant load. These improvements were achieved while maintaining a 100% request success rate. This confirms that the performance gains stem from effective workload distribution rather than reduced reliability. The integration of JWT-based authentication and WebSocket communication further complements the architecture by providing secure and low-latency interactions between clients and services. These design choices address common limitations of traditional decision support systems. They result in a flexible, extensible, and production-ready framework. The system delivers accurate, low-latency, and horizontally scalable performance for modern data-intensive applications.

This study also contributes to the literature by comparing different YOLOv10 and YOLO26 versions for mitochondria detection. It can assist experts in detecting and counting mitochondria. Thus, it can be helpful for the early diagnosis of some diseases, such as cancer. Beyond its application-specific contributions, this study also underscores the operational viability of AI-powered scalable image analysis pipelines for biomedical use cases. By leveraging a decoupled Kafka-backed architecture and modern YOLO variants, the system enables just-in-time detection and feedback without sacrificing performance under load.

To implement the proposal in real scenarios, one of the most critical requirements would be access to a sufficiently large and diverse dataset. This includes expert-labeled bounding boxes for mitochondria, ideally verified by domain professionals (e.g., pathologists or cell biologists). Collaboration with medical institutions will be important to collect such datasets under proper ethical and data privacy regulations. It is also important to get feedback about the system from healthcare professionals and to revise the system accordingly.