I don’t do this because with a complete copy I get progressive rollouts across regions without the complexity of if statements and feature flags. That is to say, making the change twice is a feature not a bug when the changes are staggered in time.

From an operational perspective it’s much more important to ensure the code is clear and readable during an incident.

Overrides are like inheritance. They are themselves complex and add unnecessary cognitive load.

Composition is better for the common pieces that never change across regions. Think of an import statement of a common package into both the Europe and North America folders.

I easily see the one line diff among hundreds of thousands using… diff.

Regarding Africa, we’ve established 1 is a feature and 2 is a non issue, so I’d copy it again.

This approach scales both as the team scales and as the infrastructure scales. Teammates can read and comprehend much more easily than hierarchies of overrides, and changes are naturally scoped to pieces of the whole.

The "rules" for config are different. Code, test code, and config are different, their complexity scales in different ways of course.

By way of analogy for why the two configs are different, for example Two beaches are not the same because they both have very similar sand.

You really have two different configs.. You also have one set of configs. You didn't set up an application that also fetches some config that is already provided. It would be like having a test flag in both config and database, sane flag - two places.

Where config duplication goes bad is when repeatedly the same change is made across all N, local variations have to be reconciled each time and it is N sets of testing you need to do. Something like that in code is potentially more complex, more obviously a duplication of a module, just more likely to be a problem overall.

> with a complete copy

Ok, so make a build script that creates a complete copy for each separate config from the default config and the overrides. Then use the complete copies.

> I easily see the one line diff among hundreds of thousands using… diff.

Yes, and in 5 years when it's not just 1 line?

Your approach does NOT scale. You just haven't scaled yet and haven't realized this.