Walk, Don’t Race

TL;DR #

Don't Race.png

Cha-Cha-Changes #

Breaking changes happen, and the breaking occurs between the layers (e.g. UI and API, API and database). Rather than trying to release new layers simultaneously (especially with edge distribution), commit the time and effort to a four or five-step pattern that ensures the layers work perfectly at all times, losing no data

1. Create the Change You Want To Be #

Create the goal: the new schema; the new endpoint; the new protocol. Test it, benchmark it, and be happy with it. Copy and translate the old system’s data to the new system (handle the subsequent data changes in step 4)
For example, instead of changing the data type of a column, create a new column of the desired type

2. Embrace the New While Respecting the Old #

The Problem With Data #

It’s always the data

The transition depends on how the old and new systems share data

3. What Is Old Is New Again #

For Types B once all of the clients update the new dataset/column, synchronize the data from old to new to catch any missing data (e.g. data updated since step 1)

4. When Choosing Between Two Evils, Choose the Lesser One #

All the clients stop depending on the old datastore, columns, APIs, etc.

5. I Hope No One Is Using This … #

Once all the clients stop using the old datastore, remove it

Make it invisible with a Proxy #

If one cannot influence one’s clients to participate in the hijinks described above, create a proxy or facade with the old system’s interface that will do the double-updates to the new system and, when ready, use the new system for getting data

This proxy can remain as a translation layer or deprecate as clients lose the option of the old interface

 
0
Kudos
 
0
Kudos

Now read this

You Don’t Know Why I’ve Called You

An advantage of functions (or methods or subroutines) is boxing up a part of a process so it does not clutter up the code that calls it. Like telling one’s spouse to “take out the trash”, it reduces all an operation’s steps into a single... Continue →