This is actually a topic that I think about from time to time: how to do aggressive changes to software while they are running. In Ruby world you have monkeypat

This is actually a topic that I think about from time to time: how to do aggressive changes to software while they are running. In Ruby world you have monkeypatching. And Linux kernel has livepatching. For example, if you have a distributed system and you want to upgrade a component that every caller uses: you have a large exercise on your hands where you might have to roll out a change over time and then clean up your incremental branches where you have to handle two control flow paths through the code. It reminds me of Google's protobuf required field discussions. It reminds me of repository-per-microservice and a Java library that other microservices use and updating a dependency and having to deploy the change to every service. It's like trying to change wheels on a car while the car is moving or refueling a jet in flight. Unison lang is trying to solve this problem I think, by allowing multiple versions of a function to be available. https://www.unison-lang.org/ https://www.unison-lang.org/ Migrations in databases are painful too. One solution I've thought of which is probably overengineered is that API call sites are an abstract object and their schema and arguments is centrally deployed, I called this "protocol manager". The idea is you write all your code to use a "span" and have contextual data in a span, and you can include or exclude data in a span with a non-software rollout. Your communication schema of RPC and API calls is a runtime decided thing, not hardcoded. If you have N deployed versions of code and you want to upgrade to X, you have to test 1..N to X versions. So nobody does that.