One Domain, 88 Countries: Architecture Decisions That Scale International Expansion

The Constraint That Shaped Everything

We were building a global consumer service that needed to launch across 88 countries. The business requirement was clear: one domain, one store, every country. Not 88 country-specific websites. Not regional subdomains. One unified experience that adapts to where you are and what you need.

This sounds simple until you start pulling the thread.

Authentication systems are typically scoped to specific domains. Payment processing varies by jurisdiction. Content must be localized, not just translated, but culturally adapted. Legal requirements differ by country, sometimes by region within a country. And the service needed to work in countries where the parent company had no existing retail presence.

The fundamental tension: the business needed a single global experience, but the underlying infrastructure was built for marketplace-specific boundaries. Every technical decision was shaped by this mismatch.

Decision 1: Path-Based Routing vs. Country Domains

The first architectural decision was how to represent country context in the URL structure.

Option A: Country-specific domains (service.example.de, service.example.fr)

• Aligns with existing marketplace infrastructure
• Each domain gets its own authentication context
• SEO benefits from country-code TLDs

Option B: Path-based routing on a single domain (service.example.com/de, service.example.com/fr)

• Single domain simplifies certificate management, DNS, and CDN configuration
• Works for countries without existing marketplace domains
• Requires solving cross-marketplace authentication differently

We chose path-based routing. The country-domain approach would have fragmented the customer journey and couldn’t serve countries without an existing marketplace domain. With path-based routing, a new country is a configuration change. With country domains, it’s DNS delegation, certificate provisioning, CDN configuration, and security review.

The tradeoff we accepted: We couldn’t rely on domain-scoped cookies for authentication. We needed a cross-domain authentication solution. Significant complexity, but complexity we could solve once rather than per-country.

Decision 2: Country Detection

How do you know which country a customer wants? We implemented a three-tier strategy with explicit priority ordering:

Tier 1: Path-based explicit selection. If the URL contains a country path, that’s definitive.

Tier 2: Stored preference. If no country is in the path, check for a previously stored preference.

Tier 3: Geolocation inference. First-time visitor, no path, no preference; infer from IP.

The priority ordering matters. We deliberately made explicit customer choice the strongest signal, not geolocation. A German customer traveling in Spain still wants German-language content. Geolocation tells you where someone is, not where they want to be served.

For geolocation, we chose CDN-level headers over a dedicated geolocation service. The service would have added ~400ms P90 latency per request. CDN headers provide ~99% accuracy at zero additional latency. The tradeoff: CDN geolocation can be fooled by VPNs. We mitigated this by making country switching easy and prominent.

Decision 3: Configuration-Driven Country Expansion

The most impactful decision wasn’t about any single country. It was about how we’d add the 87th and 88th.

Traditional approach: each country launch requires engineering work: locale files, configuration, feature flags, testing, deployment.

Our approach: a centralized metadata service that makes country launches a configuration change. It stores everything that varies by country: default locale, currency formatting, date conventions, address templates, phone formatting, marketplace association, feature availability flags.

We also built shared localization utilities consuming this service (format a currency, format a date, format an address) shared across web, mobile, and console.

The tradeoff we accepted: Centralized configuration creates a single point of failure. We mitigated with aggressive caching. Applications can operate on stale data for hours if the service is temporarily unavailable. Configuration changes infrequently enough that stale data is almost always correct data.

Decision 4: Cross-Domain Authentication

The hardest problem. Our service lived on a single domain, but customers had existing accounts on marketplace-specific domains. Authentication cookies are domain-scoped.

We needed silent authentication: click from a marketplace to our service, arrive already logged in.

We evaluated three approaches: wait for native cross-domain SSO (timeline too long), build custom token exchange (too much security surface area), or leverage existing cross-domain patterns used by other services.

We chose the third option, a proxy-based approach that accesses marketplace authentication context, establishes a session on our domain, and redirects transparently. The tradeoff: dependency on proxy infrastructure. Fallback is showing a sign-in page, degraded but not broken.

What I’d Tell Someone Starting This

1. Solve for the 88th country, not the first. If adding a country requires engineering effort, you’ve built a process, not a platform.

2. Explicit customer choice beats inference. Geolocation is a reasonable default, not a decision. Make overrides trivial.

3. Separate what varies from what doesn’t. Push country-specific behavior into configuration. Keep application logic in code.

4. Accept that authentication is the hard problem. In a multi-domain ecosystem, identity shapes everything else.

5. Configuration services need to be boring. Your country metadata service should be the most boring, reliable, well-cached service in your stack.

The Result

We launched a single global store serving customers across 88 countries with localized content, currency, formatting, and legal compliance, all driven by configuration. New country launches went from “a sprint of engineering work” to “a configuration entry and a QA pass.”

The architecture isn’t perfect. Cross-domain authentication adds latency. The metadata service is a dependency we monitor carefully. Some countries have edge cases that don’t fit cleanly.

But the system scales. And in global expansion, moving fast across markets matters more than perfection in any single one.