Configuration Over Fork

An organisation operating in many jurisdictions faces genuine variation: tax rules, invoicing formats, identity verification requirements, permitted payment methods, retention obligations, consumer-protection rules.

The two obvious responses both fail. A single rigid system cannot express real differences, so each is accommodated with a conditional until the code is unreadable and every change risks every market. A fork per market means every improvement is implemented N times, the versions diverge, and the organisation loses the ability to ship globally — and this is the more common failure, because it begins as a reasonable expedient for the second country and is irreversible by the fourth.

Configuration over fork keeps one codebase, with variation expressed as data and as adapters behind stable interfaces.

Why it matters

The measurable consequences are the ones the business cares about: time to launch a new market, and the cost of delivering one feature everywhere. A forked estate degrades both continuously, and the degradation is gradual enough that no single decision is identifiable as the mistake.

The interfaces are the actual design work. Where the extension points are drawn determines whether the next market's requirement fits or forces a fork, and an interface that is too narrow is what causes the first exception — after which the discipline erodes quickly.

Implementation patterns

• A common domain model for genuinely universal concepts — order, payment, shipment, user — with market-specific fields as extensions rather than alternative models.
• Market configuration as data: tax rules, required fields, verification levels, enabled payment methods, invoice formats, retention periods, so a new market is predominantly configuration plus a small amount of integration code.
• Adapters at the true variation points — payment rails, tax authorities, logistics, identity, invoicing — behind interfaces designed to accommodate variation that has not been seen yet.
• A rules or policy layer for jurisdictional eligibility and compliance logic, so rules change without a deployment.
• Residency as a deployment concern: the same software running in a local installation, not a different codebase.
• Configure parameters, not flow. A configuration surface that can express arbitrary behaviour is a programming language with worse tooling, no tests and no review. Tax rates and enabled methods are parameters; "this market has an extra approval step" is a flow difference belonging in code behind an extension point, where it can be tested.
• A fast path for a market team to request a core change — if it is slow, they fork, and the fork is permanent. This single process decides whether the architecture holds.

Industry example

Mercado Libre operates commerce, payments and logistics across many Latin American countries with materially different regulatory and financial environments, and its internal platform approach — standardising how services are built and operated across the organisation — is the structural response to exactly this problem: shared foundations with market variation expressed within them, rather than country-specific stacks.

The same shape appears in every multi-market platform: a core team owning the invariant model and the extension interfaces, market teams building within them, and the health of the arrangement visible in how quickly a new market can be launched.

Failure scenarios

• The first fork, taken as a one-off for a market with an urgent deadline, which never merges back.
• Extension interfaces too narrow for a requirement that arrives later, forcing a bypass.
• Configuration that expresses control flow, becoming an untested and unreviewable language.
• Market-specific logic leaking into the core as conditionals, which is the fork happening slowly.
• A slow core-change process, which guarantees forks.
• No owner for the invariant model, so it drifts toward whichever market shouted most recently.
• Time-to-launch never measured, so the architecture's degradation is invisible until a launch takes a year.

Trade-offs

The approach costs more upfront than either extreme. Designing extension interfaces before knowing all the variations requires anticipating requirements, and some anticipation will be wrong. A fork is genuinely faster for the second market, and that is why it happens.

It also constrains individual markets. A market team that could ship a local feature in a week within its own fork must instead work within the shared model, negotiate an extension, and wait — which is a real cost borne locally for a benefit realised globally, and that asymmetry is the political problem the arrangement must survive.

The trade is local speed and design effort in exchange for global shipping capability and a low marginal cost per market. It is correct when many markets are expected and the product is substantially the same in each. For two markets with genuinely different products, a fork may be the honest answer — and saying so is better than maintaining a shared model that neither market fits.

Interview question

"We are in three countries and the fourth needs an extra regulatory step in the checkout flow, in six weeks. Tell me where that logic goes, what you would refuse to make configurable, and what you would look at in a year to know whether we made the right call."