RFCs are a way for Atlassian to share what we’re working on with our valued developer community.
It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.
Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!
Summary of Project:
Realm Persistence will support partners who have already, or plan to adopt Data Residency for their Connect App, by helping to ensure that subsequent uninstallation/reinstallation events will persist to the same realm.
- Publish: 2023-08-24T14:00:00Z
- Discuss: 2023-09-07T14:00:00Z
- Resolve: 2023-09-14T14:00:00Z
Problem
Following the availability of Data Residency for Connect we’ve heard partner concerns about potential scenarios where customer’s app installations may target a different realm following reinstallation. There are two key circumstances under which this can occur:
Scenario 1:
- a customer already has an existing app installed (targeting the app’s
baseUrl
) - that app adopts data residency
- the customer uninstalls the app (notifying the baseUrl)
- the customer subsequently reinstalls the app (pointing at a different
regionBaseUrl
)
Scenario 2:
- an app adopts data residency
- a customer installs that app into their current product’s region (pointing at the same
regionBaseUrl
) - the customer uninstalls the app (notifying the
regionBaseUrl
) - the customer migrates their product to a different region
- the customer subsequently reinstalls the app (pointing at a different
regionBaseUrl
)
When this occurs, the app is reinstalled in (and traffic is routed to) a different regionBaseUrl
, but the app data may still be in the app region where the app was originally uninstalled.
For partners who have accommodated for this behaviour, this is not an issue. However, if this situation is not accounted for, customers may experience a temporary loss of data/configuration if/until the partner manually migrates their data.
Who are we solving for?
For Marketplace Partners: Realm persistence helps partners save time and avoid negative customer experience by helping to ensure that customer apps is unlikely to unexpectedly move between realms. With realm persistence, app data will only move when reinstalled outside of a defined duration or when otherwise requested to move by the customer through the realm migration service.
For customers: Realm persistence helps in reducing the likelihood of data loss when a customer reinstalls an app, by ensuring that it persists to here their data was previously stored. This is necessary for customers when using an app which otherwise does not have mechanisms or controls in place to detect and automatically migrate data to a different realm following reinstallation.
Proposed Solution
Definition in Descriptor
We are proposing that Realm Persistence can be defined within your Connect descriptor in a new declarative section, as below. By default, this behaviour is false
to persist the behaviour of existing data residency implementations.
Initially, this declaration of realmPersistence
is proposed to be optional, however to ensure explicit definition and to ensure that partners who adopt data residency are aware of the considerations regarding realm movement, it may become mandatory after some time.
{
// Existing field for base URL
"baseUrl": "https://your.sample.app.com"
...
...
// Existing field for data residency
// https://developer.atlassian.com/cloud/confluence/data-residency/#enable-data-residency
"regionBaseUrls": {
"US": "https://us.your.sample.app.com",
"EU": "https://eu.your.sample.app.com",
"AU": "https://au.your.sample.app.com",
"DE": "https://de.your.sample.app.com"
}
...
// New field data residency options
"dataResidency": {
"realmPersistence" : true, //optional
"realmPersistenceDays": 30 //optional
}
...
}
Duration of Persistence
The duration of realm persistence can also be defined within the Connect descriptor the the realmPersistenceDays
property. This is bound to a minimum of 1 day to a maximum of 30 days and defaults to 7 days when otherwise not defined in the descriptor.
Where an invalid response is provided, the default of 7 days will be utilised if realmPersistence
is true.
Asks
While we would appreciate any reactions you have to this RFC (even if it’s simply giving it a supportive “Agree, no serious flaws”), we’re especially interested in learning more about:
- Does the availability of Realm Persistence increase the likelihood of you supporting Realm Pinning and Realm Migration within your app?
- Do you have any blocking use case that will stop you from using the proposed solution to support realm persistence with data residency within Connect?
- Does the proposed adoption method and default behaviour appear reasonable? Are there concerns around the proposed requirement of this field in the future where data residency is already utilised by an app?
- Partners utilising Realm Persistence may need to provide awareness to customers about their app’s behaviour (i.e. updates to their data processing policies). Is this reasonable, or a potential blocker to adoption?
- How do you feel about the problem we are trying to solve and do you have any suggestions for us on this RFC?