You can plan scale-out for a Turnkey or other MDriven application by using the MDrivenServer distribution model when load or regional distance requires multiple servers.
What autoscaling means for MDriven applications
Autoscaling is infrastructure adding or removing application capacity in response to demand. For MDriven applications, plan this together with the MDrivenServer distribution roles:
- One MDrivenServer is the Master. It is the only server that receives data writes from users.
- Other MDrivenServers are Slaves. A Slave routes a user's save request to the Master, then receives committed data blocks from the Master and merges them into its own database.
- A Slave continuously polls the Master for changes.
For example, if users in two regions need lower latency, keep one Master and add a Slave for users in the distant region. The Slave serves its users while routing their saves to the Master.
Plan capacity and distribution
Before adding servers, decide whether the goal is increased capacity, lower regional latency, or both. MDrivenServer distribution is designed around the assumption that data reads are more common than data writes.
| Requirement | Distribution approach | Result |
|---|---|---|
| More read capacity | Add a Slave connected to the Master. | The Slave receives committed updates from the Master. |
| Lower latency for a distant user group | Place a Slave for that user group and connect it to the Master. | Users can work against the nearer Slave; saves still route to the Master. |
| Consistent writes | Keep one Master as the write receiver. | The Master accepts the save request and distributes committed data blocks. |
Prepare a server to become a Slave
Use the same model version across the cluster. Slaves are not allowed to have a model that differs from the Master because each persisted data block belongs to a particular model version. MDrivenServer stores a checksum of the current model with each commit block to manage this requirement.
You can use a backup of the Master database to deploy a new Slave because the additional table structure used for commit blocks is the same on the Master and Slaves. The commit-block information is updated in the same transaction as the business data, so it is included when the database is backed up.
Handle connectivity failures
Ensure that every Slave can reach the Master. The Slave initiates communication; the Master accepts save requests and delivers committed updates.
If a Slave cannot reach the Master:
- Users connected to that Slave cannot save data.
- The Slave does not receive updated data from the Master.
- Saving and updates resume when the Slave can reach the Master again.
Plan monitoring around this dependency so that you can detect when a Slave cannot communicate with its Master.
Deploy the application components
The Deployment section covers deployment options including Azure, Docker, Linux web servers, and CI/CD.
Autoscaling checklist
- Create each additional MDrivenServer as a Slave using a database backup from the Master where appropriate.
- Deploy the same model version to the Master and every Slave.
- Verify that each Slave can initiate communication to the Master.
- Test a save through a Slave and verify that committed updates are distributed back to that Slave.
- Test the expected behavior during a lost Slave-to-Master connection: users on that Slave cannot save until connectivity returns.
- Use your cloud platform's capacity controls only after the new-server provisioning process consistently creates a correctly configured Slave.