A mobility platform operates across several countries with different licensing, data residency, payment and labour regulations. How should regulation shape the architecture?

The central decision

Which variation is configuration and which requires separate deployment.

Getting this wrong in either direction is expensive: one global system with conditional logic everywhere becomes unchangeable, while a separate system per market multiplies engineering and operations by the number of markets.

What is usually configuration

• Pricing rules, fee structures, tax treatment — parameterised, per market.
• Document and verification requirements for drivers, expressed as a per-market checklist rather than as code.
• Payment method availability, driven by a market capability registry.
• Consent and disclosure text, and which consents are required.
• Feature availability, controlled by market-scoped flags.

The pattern: market variation lives in data, evaluated by one code path, so adding a market is configuration plus adaptation rather than a fork.

What usually requires structural separation

• Data residency. If a market requires personal data to remain within its borders, that is a deployment topology decision, not a configuration. It affects where databases live, where processing happens, where backups go, and which analytics can be global.
• Licensing that requires a separate legal entity operating the service, which can force separate infrastructure and separate access control.
• Regulator access and audit obligations that differ enough to change the audit architecture.

The properties the architecture needs

1. A market as a first-class concept, present in every record and every request, so residency and rules are enforceable rather than assumed.

2. Rules as versioned data with effective dates. Regulation changes on a date, and both the old and new rules must be applicable — for recomputing a past period, for audit, and for handling the transition.

3. Ability to answer "which data is subject to which regime", which requires classification attached at the source and propagated through derived datasets. Retrofitting this is close to impossible.

4. Per-market deployment where residency demands it, with shared code and separate data planes rather than forked codebases.

The failure to design against

Regulatory logic scattered through the application. A tax rule in the pricing service, a consent check in the signup flow, a residency assumption in an analytics pipeline. When the regulation changes, nobody can enumerate what must change, and the compliance answer becomes an investigation.

Concentrate regulatory logic in identifiable, testable places and treat "which rule applied to this transaction, and why" as a query the system can answer — because eventually a regulator will ask it.