Walk, Don’t Race


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


Now read this

Don’t Worry About Anything, Just Call Us

Callbacks are great and always have been. Long ago, we didn’t know we were injecting control or inverting dependencies; we just used them. When closures appeared, I did not see a huge difference: a little state here, a little context... Continue →