Federated Hub-and-Spoke Topology

A single parameter server acts as the hub, managing the entire training lifecycle. It selects participating clients, distributes the initial global model, and waits for updates. This star topology eliminates the need for complex peer-to-peer discovery protocols, making it the default choice for cross-silo healthcare networks where a trusted consortium lead can host the aggregator. The server never accesses raw patient data, only encrypted or masked model updates.

Most hub-and-spoke deployments use synchronous federated training. The central server waits to receive model updates from all selected clients in a round before computing the next global model via Federated Averaging (FedAvg). This ensures deterministic, reproducible aggregation but introduces a straggler problem: the entire round is delayed by the slowest participating hospital. Mitigation strategies include setting strict timeout windows or using federated client selection to exclude underperforming nodes.

The hub functions as a cryptographic aggregator, not a data lake. Using federated secure aggregation protocols, the server computes the sum of client model updates without being able to inspect any individual hospital's contribution. This is achieved through techniques like secure multi-party computation (SMPC) or homomorphic encryption, ensuring that even if the central server is compromised, no single institution's gradient updates—which could leak patient information via model inversion attacks—are exposed.

The hub provides a natural locus for federated model governance. All versioning, audit trails, and access control policies are enforced at the central server. This simplifies compliance with HIPAA and GDPR because the consortium can implement a unified federated model registry that tracks model lineage, participant contributions, and training metadata. In a federated consortium topology, the hub is typically operated by a neutral third party or lead research institution under a shared legal agreement.

The primary architectural weakness is the single point of failure and bandwidth concentration at the hub. As the number of spokes scales, the server must handle O(n) simultaneous connections. In cross-device federated learning with millions of clients, this becomes infeasible, but in cross-silo healthcare networks with 10-50 institutional nodes, it remains manageable. Hierarchical federated learning addresses this by introducing intermediate edge aggregators, effectively creating a tree of hub-and-spoke sub-networks.

The hub actively manages federated client selection, strategically choosing a subset of available hospitals for each round to maximize convergence speed. It must also handle federated client dropout, where a selected node fails to return updates due to network issues or local compute constraints. The server can either proceed with a reduced quorum, apply federated straggler mitigation techniques like gradient caching, or reschedule the dropped client for a future round without corrupting the global model state.

The centralized infrastructure component that physically stores the global model and executes the aggregation logic. In a hub-and-spoke topology, this server is the single hub that receives model updates (gradients or weights) from all spoke clients. It maintains the master state, applies the Federated Averaging (FedAvg) algorithm, and redistributes the updated global model. This component is a critical bottleneck and a single point of failure, requiring high availability and robust security hardening.

The default communication protocol for hub-and-spoke architectures. The central server selects a cohort of clients, distributes the current global model, and waits for all selected clients to return their updates before computing the next iteration. This ensures deterministic, reproducible aggregation but introduces the straggler problem, where a single slow or unresponsive hospital can delay the entire training round, wasting compute resources and wall-clock time.

A cryptographic protocol that mathematically ensures the central hub can only compute the sum of client model updates without ever inspecting any individual hospital's contribution. This is critical for healthcare because it prevents the hub operator from inferring patient-level information from a single institution's gradient update. Techniques like Secure Multi-Party Computation (SMPC) or homomorphic encryption are layered on top of the star topology to provide defense-in-depth against an honest-but-curious server.

The strategic scheduling algorithm that determines which spoke nodes participate in each communication round. In a hub-and-spoke topology with hundreds of clinics, selecting a subset is necessary to manage bandwidth and convergence. Strategies include:

• Random selection: Statistically unbiased but may pick stragglers.
• Greedy selection: Prioritizes clients with the most data or lowest latency.
• Multi-armed bandit: Dynamically balances exploration of new clients with exploitation of fast, high-quality nodes.

Techniques to prevent slow peripheral nodes from paralyzing the central hub in synchronous rounds. Common approaches include setting a hard timeout (dropping clients that don't respond within t seconds) or using asynchronous fallback where the server updates the global model immediately upon receiving a predefined quorum of updates. For healthcare deployments, straggler mitigation must be balanced against introducing bias by systematically excluding smaller, resource-constrained rural clinics.

An evolution of the flat hub-and-spoke model that introduces intermediate edge aggregators between the central server and end clients. For example, a regional hospital may act as a sub-aggregator for local clinics before forwarding a combined update to the national hub. This reduces the communication load on the central server, mitigates latency for geographically distributed nodes, and aligns naturally with healthcare administrative hierarchies like regional health information exchanges (HIEs).