Realm Sync Overview¶
Realm Sync is currently in Beta.
To sync data across devices, you can enable Realm Sync for your Realm app. Realm Sync automatically handles complex and tedious issues like data serialization, network recovery, and conflict resolution, so you can focus on the actual business logic of your app.
To understand how best to use Realm Sync, it's important to understand the problem Sync aims to address.
In order to use Realm Sync, your Atlas cluster must use MongoDB version 4.4. When setting up your cluster, select MongoDB 4.4 from the dropdown menu under Additional Settings.
The Connectivity Problem¶
Realm Database is a local, mobile database in which your app can store data. Eventually, most apps need to share that data with the outside world. Consider a few examples:
- A team collaborates in real-time on a shared document across the Internet.
- A front-line worker fills out a report while working somewhere with low or no network connectivity.
- An IoT device uploads its sensor data to the cloud.
Traditionally, developers use an HTTP client in a mobile app to manually communicate with a REST API over the Internet. This means that every mobile app needs to solve the following problems for every client platform:
- a consistent schema of objects
- gracefully handling network failures and slowdowns
- resolving conflicts between changes to the same data on different clients
Realm Sync handles network access and conflict resolution in a background thread of your application, so your application logic stays the same regardless of network conditions. The Realm data model makes it easy to manage a consistent schema of objects in your database and across all client platforms.
Realm Sync is built on the assumption that connectivity will drop. We call this mentality offline-first. After you make changes to the local realm on the client device, the Realm SDK automatically sends the changes to the server as soon as possible. Likewise, the Realm SDK automatically receives changes from the server and integrates those changes into the local realm. In effect, you continue to work with the local realm without moment-to-moment concern for network connectivity or lack thereof.
The offline-first design leads to some of the main benefits of MongoDB Realm:
- Seamless User Experience:
- Users interact with local data with zero latency regardless of their moment-to-moment connectivity.
- Live Objects Across Devices:
- MongoDB Realm's live objects concept extends across devices: updates on one device sync to the corresponding objects on other devices. Notifications based on these updates make it easy to update the application UI to react to local and remote changes.
- It's Automatic:
- Realm Sync is built into the Realm SDK. You do not need to write your own synchronization protocol and deal with connectivity issues when synchronizing data. The sync protocol is the same across platforms. MongoDB Realm handles passing the objects across the network automatically, so there is no need to map from one platform's database to another or serialize and deserialize objects in order to send and receive them over the network.
Despite these advantages, offline-first design introduces one problem: if client devices can remain offline while changes are made locally and remotely, they must share those changes when those client devices come back online. To make matters more complicated, every client device must arrive at the same state when all changes have been synced. This is why Realm Sync includes automatic conflict resolution.
MongoDB Realm's sync conflict resolution engine is deterministic. Changes received out-of-order eventually converge on the same state across the server and all clients. As such, Realm Sync is strongly eventually consistent.
From MongoDB Realm's perspective, changesets may arrive any time that connectivity allows. There is no guarantee that an earlier-timestamped changeset from one client actually arrives before a later-timestamped changeset from another client. As a result, the server has to be able to process events out-of-order. MongoDB Realm keeps a per-realm transaction history to deal with the out-of-order nature of messages.
In simple terms, Realm Sync's conflict resolution comes down to last write wins. Realm Sync also uses more sophisticated techniques like operational transform to handle, for example, insertions into lists.
Use Case Profiles and Scalability¶
In practice, reliable conflict resolution is complex and CPU-intensive. Too many writers writing on the same realm concurrently can impact performance, leading to scalability concerns.
To use Realm Sync effectively, it is important to understand the different use case profiles and their scalability implications. You can categorize Realm Sync use cases in terms of number of writers, number of readers:
- Multiple writer, multiple reader:
- The real-time collaboration app use case. Generally speaking, MongoDB Realm can handle up to 30 concurrent writers per realm. As such, each 'project' on which users can collaborate works best in its own realm.
- Single writer, multiple reader:
- A single writer, such as a publisher application on the backend, inserts data into a global realm that all frontend clients can read from but not write to. This can scale past tens of thousands of concurrent users.
- Single writer, single reader:
- Each user has their own private realm to store, e.g., user account information, preferences, or the individual user's shopping cart. As long as only the user or a backend application interacts with the realm data, the performance is ideal and scales linearly with number of users.
To get the best performance from Realm Sync, design your Realm app with use case profiles in mind. If you intend to have many concurrent writers, split projects across realms.
- Realm Sync enables offline-first app development by handling network loss and recovery automatically.
- Realm Sync has a built-in conflict resolution engine that guarantees strong eventual consistency.
- To get the best performance with Realm Sync, it is essential to understand the different use case profiles and their implications on scalability.