Partition-Based Sync

Partition

A partition is a collection of objects that share the same partition key value.

A MongoDB Atlas cluster consists of several remote servers. These servers provide the storage for your synced data. The Atlas cluster stores documents in collections. Each MongoDB collection maps to a different Realm object type. Each document in a collection represents a specific Realm object.

A synced realm is a local file on a device. A synced realm may contain some or all the objects relevant to the end user. A client app may use more than one synced realm to access all the objects that the application needs.

Partitions link objects in Realm Database to documents in MongoDB. When you initialize a synced realm file, one of its parameters is a partition value. Your client app creates objects in the synced realm. When those objects sync, the partition value becomes a field in the MongoDB documents. The value of this field determines which MongoDB documents the client can access.

At a high level:

• A partition maps to a subset of the documents in a synced cluster.

• All documents in a partition have the same read/write permissions for a given user.

• Atlas App Services maps each partition to an individual synced .realm file.

• Each object in a synced realm has a corresponding document in the partition.

Partitions shape data in an Atlas cluster. Each shape represents an object type. Partitions are determined by each shape's color: red, green, or blue.

Partition Key

A partition key is a named field that you specify when you configure Atlas Device Sync. Device Sync uses this key to determine which partition contains a given document.

Depending on your data model and the complexity of your app, your partition key could be either:

• A property that already exists in each document and that logically partitions data. For example, consider an app where every document is private to a specific user. You might store the user's ID value in an owner_id field and then use that as the partition key.

• A synthetic property that you create to partition data (e.g. _partition). You might use this when your app does not include a natural partition key.

You can make the partition key required or optional on your objects. App Services maps any object that does not include a partition key to a default partition - null partition.

Consider the following when choosing a partition key:

• Partition keys must be one of these types: String, ObjectID, Long, or UUID.

• App Services clients should never modify the partition value directly. You cannot use any field that clients can modify as a partition key.

• Partition keys use the same field name in every synced document. The partition key should not collide with any field name in any object's model.

{
  "title": "note",
  "bsonType": "object",
  "required": [
    "_id",
    "_partition",
    "owner_id",
    "text"
  ],
  "properties": {
    "_id": { "bsonType": "objectId" },
    "_partition": { "bsonType": "string" },
    "owner_id": { "bsonType": "string" },
    "text": { "bsonType": "string" }
  }
}
{
  "title": "notebook",
  "bsonType": "object",
  "required": [
    "_id",
    "_partition",
    "owner_id",
    "notes"
  ],
  "properties": {
    "_id": { "bsonType": "objectId" },
    "_partition": { "bsonType": "string" },
    "owner_id": { "bsonType": "string" },
    "notes": {
      "bsonType": "array",
      "items": { "bsonType": "objectId" }
    }
  }
}

Partition Value

A partition value is a value of the partition key field for a given document. Documents with the same partition value belong to the same partition. They sync to the same realm file, and share user-level data access permissions.

A partition's value is the identifier for its corresponding synced realm. You specify the partition's value when you open it as a synced realm in the client. If you change a partition value in Atlas, App Services interprets the change as two operations:

• A delete from the old partition.

• An insert into the new partition.

Before You Begin

You will need the following to enable Partition-Based Sync:

• An App Services App. To learn how to create an App, see Create an App.

• A linked Atlas data source. To learn how to add a data source, see Link a Data Source.

Procedure

App Services UI

App Services CLI

Admin API

1

Navigate to the Sync Configuration Screen

To define Device Sync rules and enable Device Sync for your application, navigate to the Device Sync configuration screen through the left navigation menu.

Note

Sync Rules Cannot Change

You define Device Sync rules at the same time as you enable Device Sync. Once Device Sync is enabled, you can't change your app's Device Sync rules unless you terminate Device Sync and re-enable it with new rules.

2

Select Development Details

You can enable Device Sync for a single linked cluster in your application. Determine which cluster you want to use and then select it from the Select a Cluster To Sync dropdown menu.

3

Choose a Partition Key

The Device Sync partition key is a field in every synced document that maps each document to a client-side realm. Device Sync rules apply at the partition level, so it's particularly important to consider your data model and access patterns. For more information on partition keys and how to choose one, see Partitions.

Note

The partition key can either be required or optional. If the partition key field is optional, then all MongoDB documents that either exclude the partition key or have a null value for the partition key will be sent to the null partition. If the partition key field is required, Device Sync ignores any MongoDB documents that lack a valid value for the partition key. We recommend a required partition key unless you want to Device Sync pre-existing data with invalid or missing partition values from a MongoDB collection.

4

Define Read & Write Permissions

The Define Permissions section allows you to define JSON expressions that App Services dynamically evaluates to determine a user's read and write permissions for the data in a given partition.

Device Sync rule expressions have access to %%user, which resolves to the user that opened the realm, and %%partition, which resolves to the partition key value for the realm. You can also use operators, including %function, to handle more complex cases. For examples, see Role-based Permissions.

Once you've determined how to decide a user's read and write permissions for a given partition, define the corresponding JSON expressions in the Read and Write inputs.

5

Check Default Advanced Configuration Behaviors

Expand the Advanced Configuration section.

App Services Apps provide advanced optimization features that are enabled by default:

• Client Max Offline Time

• Client Recovery

If you want to change the length of time that a client can be offline, you can do so in the Advanced Configuration section.

6

Turn On Sync

Now that you've configured rules for your synced cluster, all that's left to do is turn on Device Sync for client applications. Click Enable Sync, take note of any recommendations that appear, and then confirm your choice.

1

Authenticate a MongoDB Atlas User

Use your MongoDB Atlas Admin API Key to log in to the CLI:

appservices login --api-key="<my api key>" --private-api-key="<my private api key>"

2

Pull the Latest Version of Your App

Get a local copy of your App's configuration files. To get the latest version of your App, run the following command:

appservices pull --remote="<Your App ID>"

You can also export a copy of your application's configuration files from the UI or with the Admin API. To learn how, see Export an App.

3

Add a Sync Configuration

You can enable sync for a single linked cluster in your application.

The App Services App has a sync directory where you can find the sync configuration file. If you have not yet enabled Sync, this directory is empty.

Add a config.json similar to:

{
  "type": "partition",
  "state": <"enabled" | "disabled">,
  "development_mode_enabled": <Boolean>,
  "service_name": "<Data Source Name>",
  "database_name": "<Database Name>",
  "partition": {
    "key": "<Partition Key Field Name>",
    "type": "<Partition Key Type>",
    "permissions": {
      "read": { <Expression> },
      "write": { <Expression> }
    }
  },
  "client_max_offline_days": <Number>,
  "is_recovery_mode_disabled": <Boolean>
}

4

Choose a Partition Key

The sync partition key is a field in every synced document that maps each document to a client-side realm. Sync rules apply at the partition level, so it's particularly important to consider your data model and access patterns. For more information on partition keys and how to choose one, see Partitions.

Note

The partition key can either be required or optional. If the partition key field is optional, then all MongoDB documents that either exclude the partition key or have a null value for the partition key will be sent to the null partition. If the partition key field is required, Device Sync ignores any MongoDB documents that lack a valid value for the partition key. We recommend a required partition key unless you want to sync pre-existing data with invalid or missing partition values from a MongoDB collection.

Once you have decided which field to use, update sync.partition with the partition key field name in the key field and the partition key type in the type field, similar to:

{
  ...
  "partition": {
    "key": "owner_id",
    "type": "string",
    "permissions": {
      "read": {},
      "write": {}
    }
  }
  ...
}

5

Define Read & Write Permissions

App Services allows you to define JSON expressions that it dynamically evaluates whenever a user opens a realm to determine if the user has read or write permissions for data in the partition.

Sync rule expressions have access to %%user, which resolves to the user that opened the realm, and %%partition, which resolves to the partition key value for the realm. You can also use operators, including %function, to handle more complex cases. For examples, see Sync Permissions.

Once you've determined how to decide a user's read and write permissions for a given partition, define the corresponding JSON expressions in the read and write fields of partition.permissions, similar to:

{
  ...
  "partition": {
    "key": "owner_id",
    "type": "string",
    "permissions": {
      "read": {
        "$or": [
          { "%%user.id": "%%partition" },
          { "%%user.custom_data.shared": "%%partition" }
        ]
      },
      "write": {
        "%%user.id": "%%partition"
      }
    }
  }
  ...
}

6

Specify Values for Sync Optimization

Sync provides features that enable you to optimize Sync performance and improve the data recovery process on the client. These features are represented by additional settings:

• client_max_offline_days

• is_recovery_mode_disabled

You can set a numerical value for client_max_offline_days. When you enable Sync via the App Services UI, the default value is 30, which represents 30 days.

For more information, see: Client Maximum Offline Time.

Recovery Mode enables Sync to attempt to recover data that has not yet been synced when a client reset occurs. When you enable Sync via the App Services UI, Recovery Mode is enabled by default. We recommend enabling Recovery Mode for automatic client reset handling. If you have disabled recovery mode and want to re-enable it, set is_recovery_mode_disabled to false.

For more information, see: Recover Unsynced Changes.

{
  "type": "partition",
  "state": "enabled",
  "development_mode_enabled": true,
  "service_name": "mongodb-atlas",
  "database_name": "my-test-database",
  "partition": {
    ...
  },
  "client_max_offline_days": 30,
  "is_recovery_mode_disabled": false
}

7

Deploy the Sync Configuration

Now that you've defined the sync configuration, including read and write permissions, you can deploy your changes to start syncing data and enforcing sync rules.

To deploy your changes, import your app configuration to your App Services App:

appservices push --remote="<Your App ID>"

1

Select a Cluster to Sync

You can enable Sync for a single linked cluster in your application.

You'll need the cluster's service configuration file to configure sync. You can find the configuration file by listing all services through the Admin API:

curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/services \
  -X GET \
  -h 'Authorization: Bearer <Valid Access Token>'

Identify the service whose configuration you need to update to enable Sync. If you have accepted the default names when configuring your App, this should be a service whose name is mongodb-atlas and type is mongodb-atlas. You need this service's _id.

Now you can get the configuration file for this service:

curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/services/{MongoDB_Service_ID}/config \
  -X GET \
  -h 'Authorization: Bearer <Valid Access Token>'

Once you have the configuration, add the sync object with the following template configuration:

{
  ...
  "sync": {
    "type": "partition",
    "state": "enabled",
    "development_mode_enabled": <Boolean>,
    "database_name": "<Database Name>",
    "partition": {
      "key": "<Partition Key Field Name>",
      "type": "<Partition Key Type>",
      "permissions": {
        "read": { <Expression> },
        "write": { <Expression> }
      }
    },
    "client_max_offline_days": <Number>,
    "is_recovery_mode_disabled": <Boolean>
  }
  ...
}

2

Choose a Partition Key

The sync partition key is a field in every synced document that maps each document to a client-side realm. Sync rules apply at the partition level, so it's particularly important to consider your data model and access patterns. For more information on partition keys and how to choose one, see Partitions.

You can get a list of all valid partition keys and their corresponding types through the Admin API:

curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/sync/data?service_id=<MongoDB Service ID> \
  -X GET \
  -h 'Authorization: Bearer <Valid Access Token>'

Note

The partition key can either be required or optional. If the partition key field is optional, then all MongoDB documents that either exclude the partition key or have a null value for the partition key will be sent to the null partition. If the partition key field is required, Device Sync ignores any MongoDB documents that lack a valid value for the partition key. We recommend a required partition key unless you want to sync pre-existing data with invalid or missing partition values from a MongoDB collection.

Once you have decided which field to use, update sync.partition with the partition key field name in the key field and the partition key type in the type field.

{
  ...
  "sync": {
    "type": "partition",
    "state": "enabled",
    "development_mode_enabled": <Boolean>,
    "database_name": "<Database Name>",
    "partition": {
      "key": "owner_id",
      "type": "string",
      "permissions": {
        "read": { <Expression> },
        "write": { <Expression> }
      }
    },
    "client_max_offline_days": <Number>,
    "is_recovery_mode_disabled": <Boolean>
  }
  ...
}

3

Define Read & Write Permissions

App Services allows you to define JSON expressions that it dynamically evaluates whenever a user opens a realm to determine if the user has read or write permissions for data in the partition.

Sync rule expressions have access to %%user, which resolves to the user that opened the realm, and %%partition, which resolves to the partition key value for the realm. You can also use operators, including %function, to handle more complex cases. For examples, see Sync Permissions.

Once you've determined how to decide a user's read and write permissions for a given partition, define the corresponding JSON expressions in the read and write fields of sync.partition.permissions.

{
  ...
  "sync": {
    "type": "partition",
    "state": "enabled",
    "development_mode_enabled": <Boolean>,
    "database_name": "<Database Name>",
    "partition": {
      "key": "owner_id",
      "type": "string",
      "permissions": {
        "read": {
          "$or": [
            { "%%user.id": "%%partition" },
            { "%%user.custom_data.shared": "%%partition" }
          ]
        },
        "write": {
          "%%user.id": "%%partition"
        }
      }
    },
    "client_max_offline_days": <Number>,
    "is_recovery_mode_disabled": <Boolean>
  }
  ...
}

4

Specify Values for Sync Optimization

Sync provides features that enable you to optimize Sync performance and improve the client data recovery process. These features are represented by additional settings:

• client_max_offline_days

• is_recovery_mode_disabled

You can set a numerical value for client_max_offline_days. When you enable Sync via the App Services UI, the default value is 30, which represents 30 days.

For more information, see: Client Maximum Offline Time.

Recovery Mode enables Sync to attempt to recover unsynced data when a client reset occurs. When you enable Sync via the App Services UI, Recovery Mode is enabled by default. We recommend enabling Recovery Mode for automatic client reset handling. To enable Recovery Mode, set is_recovery_mode_disabled to false.

For more information, see: Recover Unsynced Changes.

{
  ...
  "sync": {
    "type": "partition",
    "state": "enabled",
    "development_mode_enabled": true,
    "database_name": "my-test-database",
    "partition": {
      ...
    },
    "client_max_offline_days": 30,
    "is_recovery_mode_disabled": false
  }
  ...
}

5

Deploy the Sync Configuration

Now that you've defined the sync configuration, including read and write permissions, you can deploy your changes to start syncing data and enforcing sync rules.

To deploy your changes, send an Admin API request that updates the cluster configuration with your sync configuration:

curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/services/{MongoDB_Service_ID}/config \
  -X PATCH \
  -h 'Authorization: Bearer <Valid Access Token>' \
  -d @/sync/config.json

Partition-Based Sync Rule Behavior

Sync rules apply to specific partitions and are coupled to your app's data model by the partition key. Consider the following behavior when designing your schemas to ensure that you have appropriate data access granularity and don't accidentally leak sensitive information.

• Sync rules apply dynamically based on the user. One user may have full read & write access to a partition while another user has only read permissions or is unable to access the partition entirely. You control these permissions by defining JSON expressions.

• Sync rules apply equally to all objects in a partition. If a user has read or write permission for a given partition then they can read or modify all synced fields of any object in the partition.

• Write permissions require read permissions, so a user with write access to a partition also has read access regardless of the defined read permission rules.

Partition-Based Sync Permissions

App Services enforces dynamic, user-specific read and write permissions to secure the data in each partition. You define permissions with JSON rule expressions that control whether or not a given user has read or write access to the data in a given partition. App Services evaluates a user's permissions every time they open a synced realm.

Key Concepts

Permission Strategies

You can structure your read and write permission expressions as a set of permission strategies that apply to your partition strategy. The following strategies outline common approaches that you might take to define sync read and write permissions for your app.

true

false

{ "%%true": true }

{ "%%partition": "PUBLIC" }

{
  "%%partition": {
    "$in": [
      "PUBLIC (NA)",
      "PUBLIC (EMEA)",
      "PUBLIC (APAC)"
    ]
  }
}

{ "%%user.id": "5f4863e4d49bd2191ff1e623" }

{
  "%%user.id": {
    "$in": [
      "5f4863e4d49bd2191ff1e623",
      "5f48640dd49bd2191ff1e624",
      "5f486417d49bd2191ff1e625"
    ]
  }
}

{ "%%user.custom_data.readPartitions" : "%%partition" }

{ "%%user.data.writePartitions" : "%%partition" }

{
  "%%true": {
    "%function": {
      "name": "canReadPartition",
      "arguments": ["%%partition"]
    }
  }
}

// canReadPartition
exports = async (partition) => {
  const cluster = context.services.get("mongodb-atlas");
  const permissions = cluster
    .db("myApp")
    .collection("permissions");
  const { canRead } = await permissions.findOne({ partition });
  return canRead.includes(context.user.id);
}

Migrate Partition-Based Sync Rules to App Services Rules

If you migrate your Partition-Based Sync App to Flexible Sync, your data access rules also need to migrate.

Some Partition-Based Sync rule strategies can't translate directly to App Services Rules. You may need to manually migrate permissions that include:

• %function operator.

  Function rules are not compatible with Flexible Sync and cannot be migrated.

• %%partition expansion.

  App Services Rules do not have an equivalent expansion for %%partition, so it cannot be migrated.

• %or, %not, %nor, %and expansions.

  These permissions may work, but there is enough nuance that you should test them to ensure expected behavior. Testing new permissions won't work on the App you are migrating. You'll need a new app to test manually-migrated permissions.

See the list of Flexible Sync-compatible expansions for all supported expansions.

You should also check out the Device Sync Permissions Guide for more information about how to work with permissions.

Firehose Strategy

A firehose partition strategy groups all documents into a single partition. With this structure, every user syncs all of your app's data to their device. This approach is functionally a decision to not partition data. This works for basic applications or small public data sets.

• Data Security. All data is public to clients with a realm that uses the partition. If a user has read or write access to the partition, they can read or write any document.

• Storage Capacity. Every user syncs every document in the partition. All data must fit within your most restrictive storage limitation. Use this strategy only when data sets are small and do not grow quickly.

One way to create a firehose is to set the partition key as an optional field. Don't include a value for this field in any document. App Services maps any document that doesn't include a partition value to the null partition.

You can also set a static partition value. This is when the partition value doesn't change based on the user or data. For example, realms across all clients could use the partition value "MyPartitionValue".

collection games: [
  { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... }
  { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... }
  { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... }
  { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... }
  { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... }
  { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... }
]
collection teams: [
  { name: "Brook Ridge Miners" }
  { name: "Southside Rockets" }
  { name: "Uptown Bombers" }
]

realm null: [
  Game { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... }
  Game { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... }
  Game { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... }
  Game { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... }
  Game { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... }
  Game { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... }
  Team { name: "Brook Ridge Miners" }
  Team { name: "Southside Rockets" }
  Team { name: "Uptown Bombers" }
]

User Strategy

A user partition strategy groups private documents for each user. These documents go into a partition specific to that user. This works when each document has an owner, and nobody else needs the data. A username or ID that identifies the owner makes a natural partition key.

• Data Security. Data in a user partition is specific to a given user. It may contain information private to that user. Each user syncs only their own partition. Other users cannot access documents in the partition.

• Storage Capacity. Each user only syncs data from their own partition. Their data must fit within their device's storage constraints. Use this strategy only when each user has a manageable amount of data.

collection playlists: [
  { name: "Work", owner_id: "dog_enthusiast_95", song_ids: [ ... ] }
  { name: "Party", owner_id: "cat_enthusiast_92", song_ids: [ ... ] }
  { name: "Soup Tunes", owner_id: "dog_enthusiast_95", song_ids: [ ... ] }
  { name: "Disco Anthems", owner_id: "PUBLIC", song_ids: [ ... ] }
  { name: "Deep Focus", owner_id: "PUBLIC", song_ids: [ ... ] }
]
collection ratings: [
  { owner_id: "dog_enthusiast_95", song_id: 3, rating: -1 }
  { owner_id: "cat_enthusiast_92", song_id: 1, rating: 1 }
  { owner_id: "dog_enthusiast_95", song_id: 1, rating: 1 }
]

realm dog_enthusiast_95: [
  Playlist { name: "Work", owner_id: "dog_enthusiast_95", song_ids: [ ... ] }
  Playlist { name: "Soup Tunes", owner_id: "dog_enthusiast_95", song_ids: [ ... ] }
  Rating { owner_id: "dog_enthusiast_95", song_id: 3, rating: -1 }
  Rating { owner_id: "dog_enthusiast_95", song_id: 1, rating: 1 }
]
realm cat_enthusiast_92: [
  Playlist { name: "Party", owner_id: "cat_enthusiast_92", song_ids: [ ... ] }
  Rating { owner_id: "cat_enthusiast_92", song_id: 1, rating: 1 }
]
realm PUBLIC: [
  Playlist { name: "Disco Anthems", owner_id: "PUBLIC", song_ids: [ ... ] }
  Playlist { name: "Deep Focus", owner_id: "PUBLIC", song_ids: [ ... ] }
]

Team Strategy

A team partition strategy groups private documents shared by a team of users. A team might include a store location's employees or a band's members. Each team has a partition specific to that group. All users in the team share access and ownership of the team's documents.

• Data Security. Data in a team partition is specific to a given team. It may contain data private to the team but not to a member of the team. Each user syncs partitions for the teams they belong to. Users not in a team cannot access documents in the team's partition.

• Storage Capacity: Each user only syncs data from their own teams. The data from a user's teams must fit within their device's storage constraints. Use this strategy when users belong to a manageable number of teams. If users belong to many teams, the combined realms could contain a lot of data. You may need to limit the number of team partitions synced at a time.

collection projects: [
  { name: "CLI", owner_id: "cli-team", task_ids: [ ... ] }
  { name: "API", owner_id: "api-team", task_ids: [ ... ] }
]
collection tasks: [
  { status: "complete", owner_id: "api-team", text: "Import dependencies" }
  { status: "inProgress", owner_id: "api-team", text: "Create app MVP" }
  { status: "inProgress", owner_id: "api-team", text: "Investigate off-by-one issue" }
  { status: "todo", owner_id: "api-team", text: "Write tests" }
  { status: "inProgress", owner_id: "cli-team", text: "Create command specifications" }
  { status: "todo", owner_id: "cli-team", text: "Choose a CLI framework" }
]

realm cli-team: [
  Project { name: "CLI", owner_id: "cli-team", task_ids: [ ... ] }
  Task { status: "inProgress", owner_id: "cli-team", text: "Create command specifications" }
  Task { status: "todo", owner_id: "cli-team", text: "Choose a CLI framework" }
]
realm api-team: [
  Project { name: "API", owner_id: "api-team", task_ids: [ ... ] }
  Task { status: "complete", owner_id: "api-team", text: "Import dependencies" }
  Task { status: "inProgress", owner_id: "api-team", text: "Create app MVP" }
  Task { status: "inProgress", owner_id: "api-team", text: "Investigate off-by-one issue" }
  Task { status: "todo", owner_id: "api-team", text: "Write tests" }
]

Channel Strategy

A channel partition strategy groups documents for a common topic or domain. Each topic or domain has its own partition. Users can choose to access or subscribe to specific channels. A name or ID may identify these channels in a public list.

• Data Security. Data in a channel partition is specific to a topic or area. Users can choose to access these channels. You can limit a user's access to a subset of channels. You could prevent users from accessing channels entirely. When user has read or write permission for a channel, they can access any document in the partition.

• Storage Capacity. Users can choose to sync data from any allowed channel. All data from a user's channels must fit within their device's storage constraints. Use this strategy to partition public or semi-private data sets. This strategy breaks up data sets that would not fit within storage constraints.

collection chatrooms: [
  { topic: "cats", description: "A place to talk about cats" }
  { topic: "sports", description: "We like sports and we don't care who knows" }
]
collection messages: [
  { topic: "cats", text: "Check out this cute pic of my cat!", timestamp: 1625772933383 }
  { topic: "cats", text: "Can anybody recommend a good cat food brand?", timestamp: 1625772953383 }
  { topic: "sports", text: "Did you catch the game last night?", timestamp: 1625772965383 }
  { topic: "sports", text: "Yeah what a comeback! Incredible!", timestamp: 1625772970383 }
  { topic: "sports", text: "I can't believe how they scored that goal.", timestamp: 1625773000383 }
]

realm cats: [
  Chatroom { topic: "cats", description: "A place to talk about cats" }
  Message { topic: "cats", text: "Check out this cute pic of my cat!", timestamp: 1625772933383 }
  Message { topic: "cats", text: "Can anybody recommend a good cat food brand?", timestamp: 1625772953383 }
]
realm sports: [
  Chatroom { topic: "sports", description: "We like sports and we don't care who knows" }
  Message { topic: "sports", text: "Did you catch the game last night?", timestamp: 1625772965383 }
  Message { topic: "sports", text: "Yeah what a comeback! Incredible!", timestamp: 1625772970383 }
  Message { topic: "sports", text: "I can't believe how they scored that goal.", timestamp: 1625773000383 }
]

Region Strategy

A region partition strategy groups documents related to a location or region. Each partition contains documents specific to those areas.

• Data Security. Data is specific to a given geographic area. You can limit a user's access to their current region. Alternately, give access to data on a region-by-region basis.

• Storage Capacity. Storage needs vary depending on size and usage patterns for the region. Users might only sync data in their own region. The data for any region should fit within a device's storage constraints. If users sync multiple regions, partition into smaller subregions. This helps avoid syncing unneeded data.

collection restaurants: [
  { city: "New York, NY", name: "Joe's Pizza", menu: [ ... ] }
  { city: "New York, NY", name: "Han Dynasty", menu: [ ... ] }
  { city: "New York, NY", name: "Harlem Taste", menu: [ ... ] }
  { city: "Chicago, IL", name: "Lou Malnati's", menu: [ ... ] }
  { city: "Chicago, IL", name: "Al's Beef", menu: [ ... ] }
  { city: "Chicago, IL", name: "Nando's", menu: [ ... ] }
]

realm New York, NY: [
 { city: "New York, NY", name: "Joe's Pizza", menu: [ ... ] }
 { city: "New York, NY", name: "Han Dynasty", menu: [ ... ] }
 { city: "New York, NY", name: "Harlem Taste", menu: [ ... ] }
]
realm Chicago, IL: [
 { city: "Chicago, IL", name: "Lou Malnati's", menu: [ ... ] }
 { city: "Chicago, IL", name: "Al's Beef", menu: [ ... ]  }
 { city: "Chicago, IL", name: "Nando's", menu: [ ... ]  }
]

Bucket Strategy

A bucket partition strategy groups documents by range. When documents range along a dimension, a partition contains a subrange. Consider time-based bucket ranges. Triggers move documents to new partitions when they fall out of their bucket range.

• Data Security. Limit users to read or write only specific buckets. Data may flow between buckets. Consider access permissions for a document across all possible buckets.

• Storage Capacity. Storage needs vary based on size and usage patterns for each bucket. Consider which buckets users need to access. Limit the size of buckets to fit within a device's storage constraints. If users sync many buckets, partition into smaller buckets. This helps avoid syncing unneeded data.

collection readings: [
  { bucket: "0s<t<=60s", timestamp: 1625773000383 , data: { ... } }
  { bucket: "0s<t<=60s", timestamp: 1625772970383 , data: { ... } }
  { bucket: "0s<t<=60s", timestamp: 1625772965383 , data: { ... } }
  { bucket: "60s<t<=300s", timestamp: 1625772953383 , data: { ... } }
  { bucket: "60s<t<=300s", timestamp: 1625772933383 , data: { ... } }
]

realm 0s<t<=60s: [
  Reading { bucket: "0s<t<=60s", timestamp: 1625773000383 , data: { ... } }
  Reading { bucket: "0s<t<=60s", timestamp: 1625772970383 , data: { ... } }
  Reading { bucket: "0s<t<=60s", timestamp: 1625772965383 , data: { ... } }
]
realm 60s<t<=300s: [
  Reading { bucket: "60s<t<=300s", timestamp: 1625772953383 , data: { ... } }
  Reading { bucket: "60s<t<=300s", timestamp: 1625772933383 , data: { ... } }
]