Modular Federated Learning Frameworks

Updated 27 April 2026

Modular FL frameworks are systems with composable and extensible modules that allow researchers to flexibly configure, evaluate, and deploy FL algorithms.
They employ plug-and-play subcomponents with clear data/control flow separation, supporting various modules such as aggregators, partitioners, and privacy plugins.
They support multiple paradigms—from synchronous to asynchronous and personalized FL—and ensure reproducibility with declarative configurations, scalability, and robust benchmarking.

Modular Federated Learning (FL) frameworks are systems architected for maximum composability, extensibility, and separation of concerns across the federated learning lifecycle. They allow researchers and practitioners to flexibly configure, evaluate, and extend FL algorithms, topologies, and system behavior by exposing fine-grained extension points and lightweight interfaces, enabling rapid prototyping, comparative benchmarking, and robust deployment across heterogeneous research and production environments.

1. Architectural Principles of Modular FL Frameworks

The design of modular FL frameworks centers on plug-and-play subcomponents, unified interfaces, and clear data/control flow separation. Core architectural elements include:

Component Decoupling: Critical subsystems—such as data distribution, client/server orchestration, aggregation logic, adaptation policies, network topology, and privacy/compression plugins—are exposed as independently swappable modules, each conforming to a minimal, well-specified protocol or interface (Liao et al., 9 Dec 2025, Chen et al., 2024, Vicente et al., 13 May 2025, Tyagi et al., 23 Sep 2025).
Declarative Configuration: System and experiment meta-parameters are specified up front using YAML or JSON schemas, supporting runtime composability without code intervention. Mappings from config fields to module instantiation are managed via registries or factory patterns (Chen et al., 2024, Tyagi et al., 23 Sep 2025, Liao et al., 9 Dec 2025).
Registry/Discovery Mechanisms: Modules (e.g., models, aggregators, partitioners) are dynamically discoverable, registered at load time, and imported at runtime based on configuration specifics. This enables both baseline re-use and insertion of user-defined extensions without modification of the framework core (Liao et al., 9 Dec 2025, Chen et al., 2024, Wang et al., 2023, Mukherjee et al., 15 Jul 2025).
Clean Data/Control Flow Separation: Architectures explicitly distinguish between the flow of model parameters/metrics (data-flow) and adaptation/control commands (control-flow), often by separating server/engine and adaptation/MAPE (Monitor, Analyzer, Planner, Executor) roles (Liao et al., 9 Dec 2025, Vicente et al., 13 May 2025).

2. Extension Points and Component Abstractions

Modular FL frameworks define extension points through abstract base classes or protocols for each major subsystem. Common extension points include:

Aggregation and Update Strategies: Modules such as FedAvg, FedProx, FedAdam, SCAFFOLD, and personalized FL objectives are exposed via interfaces with signatures like aggregate({Δθ}, weights) and local_objective(θ, data) (Liao et al., 9 Dec 2025, Chen et al., 2024, Tyagi et al., 23 Sep 2025).
Scheduling/Client Selection: IScheduler-like interfaces specify client selection by round, enabling injective strategies for straggler-resilience or fairness (Chen et al., 2024, Banerjee et al., 3 Jul 2025).
Data Distribution: IPartitioner or DatasetDistributor modules control IID/non-IID splits—supporting label-, Dirichlet-, or shard-based allocation (Mukherjee et al., 15 Jul 2025, Chen et al., 2024, Arafeh et al., 2022).
Network Topology: Pluggable modules support client–server, hierarchical, decentralized/peer-to-peer overlays, with custom communication logic (Mukherjee et al., 15 Jul 2025, Tyagi et al., 23 Sep 2025).
Personalization and Alignment: Modules for per-client objectives, model clustering, or alignment constraints are implemented via local objective interfaces or direct control of the global/local parameter coupling (e.g., FedProx, pFedMe) (Chen et al., 2024, Vicente et al., 13 May 2025).
Privacy/Compression: Differential Privacy, Homomorphic Encryption, Secure Aggregation, and compression schemes (TopK, QSGD, PowerSGD) are injected as decorators or plugin objects with signature-conforming APIs (Tyagi et al., 23 Sep 2025, Vicente et al., 13 May 2025).
Monitoring/Adaptation: Self-adaptive controllers expose hooks for ingesting metrics, triggering early stop, or dynamically switching aggregation strategies in response to runtime signals (Liao et al., 9 Dec 2025).

A table illustrates typical module interfaces and composability:

Module Type	Example Interface Signature	Representative Frameworks
Aggregator	`aggregate({Δθ_k}, weights)`	FedLAD, FedModule, FLsim
Partitioner	`split(data, config) -> {data_k}`	FedModule, FLGo, ModularFed
Topology	`build_graph() -> nx.Graph`	OmniFed, FLsim
Privacy Plugin	`apply_dp(g)`, `record_privacy_loss()`	OmniFed, FLsim
Scheduler	`select(round, clients) -> subset`	FedModule, Flotilla

3. System Paradigms and Supported Workflows

Modular FL frameworks support a diverse spectrum of system paradigms and enable rapid switching between them using configuration changes:

Synchronous FL: All clients synchronize at each round, supporting standard aggregation schemes and controlling participation via IScheduler. (Chen et al., 2024, Liao et al., 9 Dec 2025, Mukherjee et al., 15 Jul 2025)
Asynchronous FL: Clients operate and communicate updates at different rates; server applies mixing or staleness-aware updates. Asynchronous aggregators can be hot-swapped in place of synchronous via configuration (Chen et al., 2024, Banerjee et al., 3 Jul 2025, Liao et al., 9 Dec 2025).
Personalized and Clustered FL: Each client optimizes for a personalized objective, e.g. via per-client regularization or model clustering, realized by pluggable personalization modules (Chen et al., 2024, Vicente et al., 13 May 2025).
Hierarchical/Decentralized FL: Topology modules instantiate multi-level or non-centralized patterns, supporting, e.g., group aggregators, peer-to-peer graphs, or federated clusters (Mukherjee et al., 15 Jul 2025, Tyagi et al., 23 Sep 2025, Arafeh et al., 2022).
Stateless/Resilient Training: System designs like Flotilla decouple client state, enabling rapid client/server failover via centralized, checkpointed session state and externalized metadata (Banerjee et al., 3 Jul 2025).

4. Experimental Benchmarks, Evaluation, and Reproducibility

Modular FL frameworks enable controlled, reproducible, and comparable experimentation through:

Extensive Benchmarks: Out-of-the-box workloads include image (CIFAR-10, SVHN), text (Shakespeare, Reddit), time-series (UCIHAR), and graph domains with multiple distribution and partition strategies (Wang et al., 2023, Mukherjee et al., 15 Jul 2025, Chen et al., 2024).
Uniform Logging and Metrics: Frameworks record round-level metrics (accuracy, loss, F1, resource use, communication overhead), and support integration with standard experiment dashboards (e.g., Weights & Biases, Grafana) (Liao et al., 9 Dec 2025, Wang et al., 2023, Mukherjee et al., 15 Jul 2025).
Parallelization and Scalability: Multi-process and distributed simulation backends facilitate scaling to 1000+ clients across CPUs, GPUs, and edge hardware, with framework overheads measured and reported per configuration (Banerjee et al., 3 Jul 2025, Mukherjee et al., 15 Jul 2025, Chen et al., 2024).
Reproducibility Guarantees: Deterministic seeds, declarative experiment configs, containerized environments, and code versioning ensure result replicability across hardware and runs (Liao et al., 9 Dec 2025, Mukherjee et al., 15 Jul 2025, Wang et al., 2023).
Parameter Tuning Utilities: Automated grid or random search for hyperparameter tuning integrated into the experiment submission pipeline (Wang et al., 2023).

5. Meta-Frameworks, Taxonomies, and Comparative Analysis

Recent work systematizes the conceptual architecture of modular FL in the form of meta-frameworks that standardize component definitions, formal roles, and operator taxonomy:

Meta-Framework Decomposition: FL systems are modeled as a composition of orthogonal modules—covering infrastructure, communication, aggregation ( $\mathcal G$ ), alignment ( $\mathcal A$ ), security, privacy, data handling, and trustworthiness—with all major frameworks mapped to their supported module axes (Vicente et al., 13 May 2025).
Aggregation vs. Alignment Distinction: The aggregation operator $\mathcal G$ (e.g., weighted averaging) is separated from alignment operators $\mathcal A$ (e.g., inter-client consensus, fairness or diversity constraints). This split provides analytical and practical leverage for enforcing constraints beyond simple averaging (Vicente et al., 13 May 2025).
Framework Comparison: Comparative benchmarks reveal that only a subset of frameworks (e.g., FLsim, FedModule, OmniFed) support full modularity across communication, synchronization mode, privacy, topologies, and algorithmic extensibility. Others, such as FLGo and fluke, emphasize rapid algorithmic prototyping or plugin-based evaluation, while enterprise platforms (Flower, FATE, NVFlare) may prioritize deployment or privacy (Vicente et al., 13 May 2025, Chen et al., 2024, Tyagi et al., 23 Sep 2025, Wang et al., 2023).

A representative mapping:

Framework	Aggregation	Personalized FL	Privacy	Topology	Async FL	Pluginization
FedModule	✓	✓	DP	any	✓	✓
FLsim	✓	via custom	DP/HE	any	✓	✓
Flotilla	✓	user-defined	DP/HE	any	✓	✓
FLGo	✓	✓	–	any	partial	✓
Flower	✓	✓	DP	limited	partial	limited

6. Open Challenges and Best Practices

Key challenges and best practices in modular FL framework design include:

Complexity Management: Decoupling adaptation logic from FL training engines aids clarity and maintainability (Liao et al., 9 Dec 2025).
Abstraction Generality vs. Performance: Library/middleware agnostic interfaces (as in FLsim) promote flexibility but can introduce overhead or abstraction leakage (Mukherjee et al., 15 Jul 2025). Ensuring efficient resource handling (e.g., memory, communication) at scale requires careful design.
Reproducibility: Comprehensive experiment metadata capture (seeds, configs, code versions) and containerization are essential for scientific rigor (Liao et al., 9 Dec 2025, Mukherjee et al., 15 Jul 2025).
Community Extension: Registry/factory patterns, plugin-based benchmarks, and pip-installable extension modules lower the barrier for researchers to contribute and benchmark novel FL strategies (Wang et al., 2023, Liao et al., 9 Dec 2025).
Adaptive Control Loops: Embedding self-monitoring, auto-configuration, and MAPE-style adaptation as first-class citizens allows dynamic response to distribution drift and performance stagnation (Liao et al., 9 Dec 2025).
Interoperability: Unified platforms (e.g., UniFed) facilitate cross-framework evaluation by standardizing configuration schemas and adapter APIs, allowing one-click comparative benchmarking (Liu et al., 2022).

7. Representative Implementations and Blueprint Frameworks

Several frameworks exemplify the modular philosophy:

FedLAD (Liao et al., 9 Dec 2025): Four-tier decomposition (design-time, adaptation control, FL engine, simulated environment), abstract base classes, registry mechanism, and MAPE adaptation loops for federated log anomaly detection.
FedModule (Chen et al., 2024): Core-and-repository split, dynamic loader for all paradigms, “one code, all scenarios” design, and extensive execution modes spanning simulation to cross-device distributed deployment.
FLsim (Mukherjee et al., 15 Jul 2025): Full library-agnosticism, user-declared experiment configs, custom network topologies, pluggable blockchain and consensus support, and deterministic, scalable simulation.
OmniFed (Tyagi et al., 23 Sep 2025): Configuration-driven orchestration, coexisting communication protocols, privacy/compression decorators, and reference YAMLs for edge/HPC scenarios.
ModularFed (Arafeh et al., 2022): Protocol-oriented layering, plug-in subscribers, built-in non-IID data distributors, and wrapping for fair multi-approach evaluation.
ModFL (Liang et al., 2022): Two-module splitting for configuration and operation, cohort-specific aggregation, and explicit support for distributed device and label heterogeneity.

These systems collectively provide a technical blueprint for the next generation of scalable, reproducible, and easily extensible federated learning research infrastructure.

References:

(Liao et al., 9 Dec 2025) "FedLAD: A Modular and Adaptive Testbed for Federated Log Anomaly Detection"
(Chen et al., 2024) "FedModule: A Modular Federated Learning Framework"
(Mukherjee et al., 15 Jul 2025) "FLsim: A Modular and Library-Agnostic Simulation Framework for Federated Learning"
(Banerjee et al., 3 Jul 2025) "Flotilla: A scalable, modular and resilient federated learning framework for heterogeneous resources"
(Arafeh et al., 2022) "ModularFed: Leveraging Modularity in Federated Learning Frameworks"
(Vicente et al., 13 May 2025) "Modular Federated Learning: A Meta-Framework Perspective"
(Tyagi et al., 23 Sep 2025) "OmniFed: A Modular Framework for Configurable Federated Learning from Edge to HPC"
(Wang et al., 2023) "FLGo: A Fully Customizable Federated Learning Platform"
(Liang et al., 2022) "Modular Federated Learning"
(Polato, 2024) "fluke: Federated Learning Utility frameworK for Experimentation and research"
(Liu et al., 2022) "UniFed: All-In-One Federated Learning Platform to Unify Open-Source Frameworks"