3 ms·
Writing Code: if (migration_complete) { write_new_data_model(); } else if (migration_in_progress) { write_old_data_model(); write_new_d
by elgenie 10y ago
Writing Code:
if (migration_complete) {
write_new_data_model();
} else if (migration_in_progress) {
write_old_data_model();
write_new_data_model();
} else {
write_old_data_model();
}
Reading Code:
if (migration_complete) {
read_new_data_model();
} else {
read_old_data_model();
}
The `migration_in_progress` feature flag is flipped first, then the migration jobs run to backfill the new data model from the old data model, then the `migration_complete` flag is flipped. As many times as necessary, `migration_in_progress` can be flipped to off at any time and the new data model can be blown away and new writing code deployed. If there's no confidence in the code for reading the new data model, then a certain percentage of requests/users can be directed to read from the new data model while double-writing continues.
- overcast 10y agoI get the code bit, I was more curious as to how they in particular get that slipstreamed in there. Load balancing deployments as others mentioned below seems to be the most feasible.