Regions
An application may need to run in more than one place at once: close to users on different continents, or in two data centers so that the loss of one does not stop the service.
The simple arrangement, with one database shared by every location, makes each request depend on a distant database and makes that database a single point of failure. The alternative is for each location to have its own database and for the locations to agree on the data.
A region is a deployment of an application with its own infrastructure. Regions of one application converge: each ends up with the same entity state.
§The same model, one level up
Within an application, components reach agreement through events, as described in Eventual Consistency. Convergence applies the same idea between deployments.
Every committed change in one region is carried to the others, and each applies it to its own database. A region serves its users entirely from local state and local infrastructure. The link between regions affects how current a region’s data is, and does not affect whether the region can serve.
Nothing is declared in components. An application that declares regions converges everything that stores state, including the components that extensions bring. An account registered in one region exists in the others.
§Resolving concurrent writes
Two regions can change the same entity at nearly the same time, before either has heard from the other. Each region then holds a different state for it, and they have to settle on one.
The rule is simple and the same everywhere:
- the record with the higher version wins;
- where versions are equal, the region that outranks the other wins, by a rank the application declares for each region.
Every region applies this rule to every record it receives. They reach the same result whatever order the records arrive in and however often they are repeated.
§What convergence guarantees
The regions converge. Given time and a working link, every region holds the same state.
Records are replaced whole. A record that loses is discarded entirely. There is no merging of fields: if two regions change different properties of one order at the same moment, one of the two changes is lost.
It is eventual. A read in one region may be behind another by the delay of the link. Nothing is transactional across regions.
Failures stay local. An interrupted link delays convergence and nothing else. Each region continues to serve, and changes are carried across when the link returns.
§What it asks of the application
Convergence widens the window of eventual consistency from milliseconds to the delay between regions, and it adds conflicts that a single deployment cannot have. Some designs that are safe in one region are not safe in several.
Concurrent writes to one entity can be lost. An application that cannot accept this for some entity arranges for that entity to be written in one region, for example by routing each user to a home region.
Uniqueness holds only for identity. A rule such as “one account per email” is enforced within a database. Two regions can each accept the same email before hearing from the other, and the two records cannot both be kept. Identifiers assigned by the runtime do not have this problem.
Idempotency is regional. A repeated call is recognized in the region where it was first made; see Transactional Inbox. A client that retries against a different region is not recognized there.
Scheduled work has an owner. A delayed call is known in every region and made by the region that asked for it, so it is not made once per region. If a region is lost, another can be told to take over its calls.
§Regions and environments
A region is an environment that declares itself to be one. It has its own addresses and infrastructure, as any environment does, and additionally its rank and its link to the others.
An environment that declares no region is a single deployment, and none of this applies to it. The same application can run as one place in staging and as three regions in production.
§What it requires
Convergence carries changes by the same mechanism that carries events, and it has the same requirement: a storage that commits a change together with the record of it. Where an ordinary deployment degrades without that, a region refuses to start. A change lost between regions would leave them different with nothing to reveal it.
Regions are also expected to run the same components. A change to an entity has nowhere to go in a region that does not run the component that owns it.