# Micro-FL: A Fault-Tolerant Scalable Microservice-Based Platform for Federated Learning
## 6 Results
### Software Performance Analysis  
Micro-FL provides a persistent operation and communication platform for federated learning, even during faults. This demonstrates the robust fault tolerance of the proposed approach. Figure 8 illustrates the partition status during the MNIST experiment with 100 users in the presence of faults. Initially, all partitions are online and accessible. When a fault occurs, the affected Kafka broker's partitions become under-replicated but remain available due to the minimum ISR policy, thus preventing any offline partitions. This confirms the fault tolerance of Micro-FL, which provides a persistent operation and communication platform for the federated learning system, despite the presence of faults. Once the fault is resolved, the Kafka cluster quickly recovers, restoring the number of online partitions and reducing the underreplicated and minimum ISR partitions to zero, thus reaffirming the message availability. This resilient behaviour is consistent across all experiments. The Micro-FL framework effectively maintains constant throughput and CPU utilization under healthy conditions, and adapts to faults by redistributing the load among operational Kafka brokers, thereby demonstrating its fault-tolerant nature. Figure 9 presents the throughput and CPU utilization under the MNIST workload with 100 users across the three Kafka brokers in the cluster in a faulty scenario. In normal operating conditions of Micro-FL, the throughput and CPU utilization of the Kafka brokers remain relatively constant, fluctuating around a specific value. However, according to Figure 9, a distinct change is noticeable during the occurrence of a fault, with darker shades of grey marking the period of time with the faulty Kafka broker. When a fault occurs, there is a decrease in throughput and CPU utilization for the broker in question. Concurrently, a slight increase is observed in the throughput and CPU utilization of the remaining two operational Kafka brokers. This increase is an adaptive response to compensate for the faulty broker, enabling the system to continue processing messages. Once the fault is resolved, the throughput of the faulty broker remains at zero, while the CPU utilization spikes across all Kafka brokers. This is indicative of the faulty Kafka broker retrieving underreplicated partitions from the other brokers. \begin{table}
\begin{tabular}{c c c c c} \hline \multirow{2}{*}{**Dataset**} & \multirow{2}{*}{**\#Clients**} & \multicolumn{2}{c}{**Experiment Duration (s)**} & \multirow{2}{*}{**Change**} \\ \cline{3-3} \cline{5-5}  & & **Healthy** & & & \\ \hline \multirow{4}{*}{MNIST} & 100 & 5230 & 5070 & \(-\)3.06 \\  & 500 & 5888 & 6090 & 3.43 \\  & 1000 & 10,231 & 10,144 & \(-\)0.85 \\ \hline \multirow{4}{*}{CIFAR-10} & 100 & 11,160 & 11,014 & \(-\)1.30 \\  & 500 & 18,819 & 18,757 & \(-\)0.33 \\ \cline{1-1}  & 1000 & 31,256 & 31,236 & \(-\)0.06 \\ \hline \end{tabular}
\end{table} 
Table 6: Experiment execution time for healthy and faulty scenarios. Positive change indicates shortened execution time and negative change shows extended execution time. \begin{table}
\begin{tabular}{c c c c c c} \hline \multirow{2}{*}{**Dataset**} & \multirow{2}{*}{**\#Clients**} & \multicolumn{2}{c}{**Training Accuracy**} & \multicolumn{2}{c}{**Testing Accuracy**} \\ \cline{3-5}  & & **Healthy** & **Faulty** & **Healthy** & **Faulty** \\ \hline \multirow{4}{*}{MNIST} & 100 & 96.86 & 96.89 & 96.02 & 96.35 \\  & 500 & 94.24 & 93.26 & 94.07 & 93.14 \\  & 1000 & 92.76 & 92.80 & 92.83 & 93.12 \\ \hline \multirow{4}{*}{CIFAR-10} & 100 & 76.69 & 75.94 & 60.23 & 59.60 \\  & 500 & 57.78 & 59.83 & 51.90 & 55.24 \\ \cline{1-1}  & 1000 & 50.84 & 50.69 & 48.45 & 48.58 \\ \hline \end{tabular}
\end{table} 
Table 5: Training and testing accuracies of the aggregator after training the model for 100 iterations. Figure 8: Number of online and under-replicated partitions and partitions at minimum ISR for Kafka broker during the faulty scenario for MNIST with 100 users. The fault period is marked in gray.