Handling A Change to an Identifier

I have been working on how to correct an identifier sent to a third party.
Their API does not have a rename option so I have to cancel the old version and create a new entry.

This is made more difficult because we had calculated the old identifier and not stored what we sent. In addition our system uses k8s so there could be multiple versions of the same application running at the same time. This also adds the wrinkle that a failed deploy would be rolled back.

The solution that I used was a fixed cutover date in the near future. This meant that before that date the old approach was used. After that date on the first change an upgrade was applied and for new and upgraded it would use the new correct identifier.

This does involve having code that can be removed at various points.
The pre code can be removed as soon as we know we are not rolling back.

The upgrade code will have to live for a year (the lifetime of the value in the third party service).

This gives an interesting option when structuring the code: plan for deletion. It is worth living with slightly more duplication than is normal so that the deletion can become much cleaner.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s