Online Federated Learning
Online Federated Learning (Sequential Distributed Learning without Centralised Data) · Also known as: OFL, federated online learning, streaming federated learning, real-time federated learning
Online Federated Learning (OFL) combines the privacy-preserving, decentralised structure of federated learning with the sequential, sample-by-sample update regime of online learning. Clients — such as mobile devices or edge sensors — receive a global model, update it on newly arriving local data without sharing raw observations, and contribute compressed updates to a central server that aggregates them in near-real-time.
Read the full method
Sign in with a free account to read this section.
Method map
The neighbourhood of related methods — select a node to explore.
When to use it
Use Online Federated Learning when (1) data is naturally distributed across many edge devices or organisations and cannot legally or practically be centralised, (2) data arrives as a continuous stream and the model must adapt in near-real-time rather than from a fixed snapshot, and (3) privacy, bandwidth, or latency constraints rule out uploading raw data. Typical domains include mobile keyboard prediction, medical wearables, IoT sensor networks, and financial fraud detection across institutions. Do NOT use it when you can centralise data freely and have a stable, fixed dataset — standard batch federated learning or centralised deep learning will be simpler and easier to tune. Also avoid OFL when device populations are too small to yield diverse updates or when you have no mechanism to handle severe statistical heterogeneity across clients.
Strengths & limitations
- Strong privacy guarantee: raw data never leaves the originating device, satisfying GDPR and HIPAA constraints in many deployments.
- Adapts continuously to concept drift and non-stationary environments, unlike batch-trained models that go stale.
- Scales to millions of heterogeneous edge clients without requiring centralised storage or compute proportional to total data.
- Reduces communication cost compared to uploading full datasets: only compact gradient updates or model deltas are transmitted.
- Naturally leverages idle compute on edge devices, distributing training cost across the client population.
- Convergence is harder to guarantee than in centralised training: statistical heterogeneity (non-IID data across clients) and system heterogeneity (varying device speeds) can slow or destabilise learning.
- Requires careful design of the communication schedule, aggregation rule, and learning rate; naive settings lead to client drift or divergence.
- Debugging and monitoring are difficult because the training process is opaque — the server cannot inspect local data or local gradients in full.
- Secure aggregation and differential privacy mechanisms add computational and communication overhead.
- Evaluation is non-trivial: standard centralised test sets may not reflect the heterogeneous distribution seen across clients.
Frequently asked
How is Online Federated Learning different from standard Federated Learning?
Standard federated learning assumes a fixed, pre-collected local dataset on each client and trains over multiple rounds on that static data. Online Federated Learning extends this to streaming settings where new data arrives continuously and the model must update sequentially, making it suitable for non-stationary environments and concept drift.
Does it provide formal privacy guarantees?
Not automatically. The basic OFL framework keeps raw data local, which is a strong practical privacy safeguard, but a formal differential privacy guarantee requires adding calibrated noise to local gradients or the aggregated update before transmission. Many production deployments combine OFL with secure aggregation and local differential privacy.
How do I handle non-IID data distributions across clients?
Several strategies exist: FedProx adds a proximal term that regularises local updates toward the global model; SCAFFOLD uses control variates to correct for client drift; personalised federated learning fine-tunes the global model locally for each client. The best choice depends on how heterogeneous the client distributions are.
What sample size is needed per client?
There is no universal minimum, but extremely small local batches (e.g., 1–5 samples per round) produce very noisy updates. A common heuristic is at least 10–50 local samples per update round. Aggregating over more clients partially compensates for noisy individual updates.
Can Online Federated Learning be used without a central server?
Yes — decentralised or peer-to-peer federated learning variants allow devices to exchange model updates directly via a gossip protocol or ring topology, eliminating the central server bottleneck. This adds complexity but improves fault tolerance and removes a single point of trust.
Sources
- Damaskinos, G., Guerraoui, R., Kermarrec, A.-M., Guirguis, A., Riviere, M., & Tempo, R. (2020). FLEET: Flexible and Efficient Federated Learning for Edge AI. Proceedings of Machine Learning and Systems (MLSys). link ↗
- McMahan, B., Moore, E., Ramage, D., Hampson, S., & Aguera y Arcas, B. (2017). Communication-Efficient Learning of Deep Networks from Decentralized Data. Proceedings of the 20th International Conference on Artificial Intelligence and Statistics (AISTATS), 54, 1273–1282. link ↗
How to cite this page
ScholarGate. (2026, June 3). Online Federated Learning (Sequential Distributed Learning without Centralised Data). ScholarGate. https://scholargate.app/en/machine-learning/online-federated-learning
Which method?
Set this method beside its closest kin and read them side by side — the library lays the books on the table; the choice is yours.
- Differential PrivacyPrivacy↔ compare
- Federated LearningPrivacy↔ compare
- Online LearningMachine learning↔ compare
- Stochastic Gradient DescentMachine learning↔ compare
- Transfer LearningMachine learning↔ compare