An enterprise platform serving many countries keeps hitting jurisdiction-specific rules - different approval chains, retention periods, mandatory fields and tax treatments - that vary independently of each other. Which accommodation holds up as the number of jurisdictions grows?
Show the full answer Hide the answer
The deciding property
The dimensions vary independently. Retention period does not correlate with approval chain, which does not correlate with mandatory fields. That means the number of distinct combinations grows multiplicatively while the number of rules grows additively. Any approach that materialises combinations - a branch, a deployment, a flag per behaviour - grows with the combinations. Only one that treats the rules as data grows with the rules.
This is the structural reason enterprise software vendors such as SAP and Oracle ship localisation as configurable rule content rather than as country-specific builds: a vendor supporting 100 countries cannot maintain 100 variants of its own product.
Why the rule set wins
- Adding a country becomes a data change, reviewable by someone who understands tax law rather than requiring an engineer and a release.
- The rules are inspectable and testable in isolation, which matters when an auditor asks what the retention period for one country was on a date last year - answerable from versioned configuration, not from a code archaeology exercise.
- The engine is written once. Complexity concentrates in one well-tested component instead of dispersing through the codebase.
Why the other options fail
- "Per-country deployment with local modifications." The classic enterprise failure. Each deployment diverges, security patches must be applied N times, and after three years there is no product - there are N products with a shared ancestor. It is the fastest option for country two and the most expensive for country twelve.
- "Feature flags per behaviour." Flags are for temporary divergence; these differences are permanent. With four independent dimensions across twenty countries you get an unbounded flag matrix nobody can reason about, and the combinations are untestable - the exact condition that causes flag-interaction incidents.
- "A service per country." Correct-looking, and it duplicates the entire business capability per country to vary 5% of it. The shared 95% then drifts, which is worse than the monolith it replaced.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| Countries differ in the process, not just its parameters | Separate services or workflows | A rule engine that must express different control flow becomes a bad programming language |
| Data residency forbids shared storage | Per-region deployment of the same build | Residency is about where data sits; keep one build and vary the deployment |
| Two or three countries only | Conditionals in code | The engine costs more than the duplication it prevents |
When this is the wrong answer
Below about four jurisdictions, a rule engine is over-engineering: the abstraction costs more than the if-statements it replaces, and it is built before anyone knows which dimensions actually vary. The honest sequence is conditionals first, extract the engine when the third dimension appears, and the mistake to avoid is building the engine from a prediction rather than from three observed variations.