Each market may use a different language, currency, address format, category structure and URL pattern. If these differences are added without a clear architecture, the application can quickly become difficult to maintain.

This article describes a practical way to organise country-specific routes and settings in a multi-market web application.

The Main Challenge

Imagine an application that supports four markets:

• United States

• Ukraine

• Canada

• United Kingdom

The application needs to show different content depending on the selected country.

For example:

• The United States uses USD and ZIP codes.

• Ukraine uses UAH and Ukrainian regional data.

• Canada uses provinces and postal codes.

• The United Kingdom uses GBP and UK postcodes.

The application may also use different terminology.

A property in the United States may be described as an apartment, while British users often expect the word flat.

A phone number, date, price and address may also need different formatting.

The application should handle these differences without creating a completely separate codebase for every country.

Use a Market Configuration Object

A simple solution is to store market-specific settings in one configuration object.

type MarketCode = "US" | "UA" | "CA" | "GB";

interface MarketConfig {
  code: MarketCode;
  path: string;
  language: string;
  currency: string;
  locale: string;
  postcodeLabel: string;
  timezone: string;
}

const markets: Record<MarketCode, MarketConfig> = {
  US: {
    code: "US",
    path: "",
    language: "en",
    currency: "USD",
    locale: "en-US",
    postcodeLabel: "ZIP code",
    timezone: "America/New_York",
  },
  UA: {
    code: "UA",
    path: "/ua",
    language: "uk",
    currency: "UAH",
    locale: "uk-UA",
    postcodeLabel: "Поштовий індекс",
    timezone: "Europe/Kyiv",
  },
  CA: {
    code: "CA",
    path: "/ca",
    language: "en",
    currency: "CAD",
    locale: "en-CA",
    postcodeLabel: "Postal code",
    timezone: "America/Toronto",
  },
  GB: {
    code: "GB",
    path: "/gb",
    language: "en",
    currency: "GBP",
    locale: "en-GB",
    postcodeLabel: "Postcode",
    timezone: "Europe/London",
  },
};

This structure keeps the main market differences in one place.

When a new country is added, the development team can create another configuration entry instead of changing many unrelated components.

Detect the Market from the URL

The next step is to identify the selected market from the URL.

For example:

/                 United States
/ua               Ukraine
/ca               Canada
/gb               United Kingdom

A basic resolver can inspect the first path segment.

function resolveMarket(pathname: string): MarketConfig {
  const firstSegment = pathname.split("/").filter(Boolean)[0];

  if (firstSegment === "ua") {
    return markets.UA;
  }

  if (firstSegment === "ca") {
    return markets.CA;
  }

  if (firstSegment === "gb") {
    return markets.GB;
  }

  return markets.US;
}

This function can be called on the server or client, depending on the framework.

For server-rendered applications, market detection should usually happen before the page is rendered. This allows the correct language, currency and metadata to be loaded immediately.

Keep Country and Language Separate

Country and language should not be treated as the same value.

Canada, for example, may support both English and French. The United States and the United Kingdom both use English, but they use different spelling, currency and address formats.

A better structure separates these concepts:

interface UserContext {
  market: MarketCode;
  language: string;
  currency: string;
}

A user may have:

const context: UserContext = {
  market: "CA",
  language: "fr",
  currency: "CAD",
};

This makes future localisation easier.

Format Prices with Intl.NumberFormat

Prices should not be formatted manually.

JavaScript provides Intl.NumberFormat, which supports local currency formatting.

function formatPrice(
  amount: number,
  locale: string,
  currency: string
): string {
  return new Intl.NumberFormat(locale, {
    style: "currency",
    currency,
  }).format(amount);
}

Example usage:

formatPrice(1250, "en-US", "USD");
// $1,250.00

formatPrice(1250, "en-GB", "GBP");
// £1,250.00

formatPrice(1250, "uk-UA", "UAH");
// 1 250,00 грн

This approach reduces formatting errors and respects local conventions.

Adapt Address Forms by Market

A single address form may not work well for every country.

Different markets use different administrative divisions.

For example:

const addressFields = {
  US: {
    regionLabel: "State",
    postcodeLabel: "ZIP code",
  },
  UA: {
    regionLabel: "Region",
    postcodeLabel: "Поштовий індекс",
  },
  CA: {
    regionLabel: "Province",
    postcodeLabel: "Postal code",
  },
  GB: {
    regionLabel: "Country",
    postcodeLabel: "Postcode",
  },
};

The form component can read these values from the selected market configuration.

function AddressForm({ market }: { market: MarketCode }) {
  const fields = addressFields[market];

  return (
    <form>
      <label>
        City
        <input name="city" />
      </label>

      <label>
        {fields.regionLabel}
        <input name="region" />
      </label>

      <label>
        {fields.postcodeLabel}
        <input name="postcode" />
      </label>
    </form>
  );
}

For production applications, region fields should usually use validated lists rather than unrestricted text fields.

Store Categories by Country

Not every category should be shared across all markets.

Different countries may use different names and category structures.

A category record can include a country field:

interface Category {
  id: string;
  name: string;
  slug: string;
  country: MarketCode;
  parentId?: string;
}

Example:

const categories: Category[] = [
  {
    id: "1",
    name: "Mobile Phones",
    slug: "mobile-phones",
    country: "GB",
  },
  {
    id: "2",
    name: "Мобільні телефони",
    slug: "mobilni-telefony",
    country: "UA",
  },
];

When loading categories, the application should filter them by the selected market.

function getCategoriesForMarket(
  categories: Category[],
  market: MarketCode
): Category[] {
  return categories.filter(category => category.country === market);
}

This prevents categories from one country appearing in another market.

Generate Consistent URLs

A reusable URL builder helps avoid incorrect country paths.

function buildMarketUrl(
  market: MarketCode,
  pathname: string
): string {
  const basePath = markets[market].path;
  const cleanPath = pathname.startsWith("/")
    ? pathname
    : `/${pathname}`;

  return `\({basePath}\){cleanPath}`;
}

Example:

buildMarketUrl("US", "/vehicles");
// /vehicles

buildMarketUrl("UA", "/transport");
// /ua/transport

buildMarketUrl("CA", "/vehicles");
// /ca/vehicles

buildMarketUrl("GB", "/cars-vehicles");
// /gb/cars-vehicles

Centralising this logic reduces broken links and incorrect route prefixes.

Handle Canonical URLs Carefully

Country-specific pages should have their own canonical URLs when the content is intended for different markets.

For example:

<link
  rel="canonical"
  href="https://example.com/gb/cars-vehicles"
/>

Do not automatically point all country versions to the main United States page.

If the page has local categories, currency, content or locations, it may be a separate and useful page for search engines.

Applications with translated alternatives can also use hreflang.

<link
  rel="alternate"
  hreflang="en-us"
  href="https://example.com/vehicles"
/>

<link
  rel="alternate"
  hreflang="uk-ua"
  href="https://example.com/ua/transport"
/>

<link
  rel="alternate"
  hreflang="en-ca"
  href="https://example.com/ca/vehicles"
/>

<link
  rel="alternate"
  hreflang="en-gb"
  href="https://example.com/gb/cars-vehicles"
/>

The URLs should represent real regional content. They should not exist only for search engine optimisation.

Avoid Automatic Redirects That Block Users

IP-based country detection can be useful, but forced redirects may create problems.

A user in Ukraine may want to browse the Canadian market. A Canadian user may be travelling in another country.

A safer approach is:

1. Detect the likely country.

2. Suggest the local version.

3. Allow the user to stay on the current market.

4. Save the selected market in a cookie or account preference.

Example:

interface MarketPreference {
  detectedMarket: MarketCode;
  selectedMarket: MarketCode;
  manuallySelected: boolean;
}

The manually selected market should normally have priority over automatic detection.

Validate Data on the Server

Client-side validation improves the user experience, but it is not enough.

The server should verify that:

• The selected city belongs to the selected country.

• The region belongs to the correct market.

• The currency matches the listing market.

• The category is available in that country.

• The URL path matches the stored country value.

Example:

function validateListingMarket(
  listingMarket: MarketCode,
  category: Category
): void {
  if (listingMarket !== category.country) {
    throw new Error("Category does not belong to the selected market");
  }
}

Without server validation, incorrect data can enter the database through modified API requests.

A Useful Database Structure

A simplified database structure may look like this:

CREATE TABLE markets (
  code VARCHAR(2) PRIMARY KEY,
  language VARCHAR(10) NOT NULL,
  currency VARCHAR(3) NOT NULL,
  locale VARCHAR(20) NOT NULL,
  path VARCHAR(20) NOT NULL
);

CREATE TABLE categories (
  id UUID PRIMARY KEY,
  country_code VARCHAR(2) NOT NULL,
  name VARCHAR(255) NOT NULL,
  slug VARCHAR(255) NOT NULL,
  parent_id UUID,
  FOREIGN KEY (country_code) REFERENCES markets(code)
);

CREATE TABLE listings (
  id UUID PRIMARY KEY,
  country_code VARCHAR(2) NOT NULL,
  category_id UUID NOT NULL,
  title VARCHAR(255) NOT NULL,
  description TEXT NOT NULL,
  price DECIMAL(12, 2),
  currency VARCHAR(3) NOT NULL,
  FOREIGN KEY (country_code) REFERENCES markets(code),
  FOREIGN KEY (category_id) REFERENCES categories(id)
);

This design keeps market information explicit.

It also makes it easier to filter listings and categories without depending only on URL strings.

Common Mistakes

Several mistakes are common in multi-market applications.

Hardcoding country logic in components

Avoid code such as:

if (country === "GB") {
  // many lines of UK-specific logic
}

If similar conditions are repeated throughout the application, maintenance becomes difficult.

Move differences into configuration objects or specialised services.

Using one currency globally

Currency should be stored with the listing or derived from a validated market.

Never assume that every listing uses the application's default currency.

Mixing location data

A city from one country should not be available in another country's address form.

Location data needs relationships between countries, regions and cities.

Duplicating entire applications

Creating a separate application for every country may seem simple at first, but it creates duplicated code and inconsistent features.

A shared codebase with market-specific configuration is usually easier to maintain.

Translating without localisation

Translation changes words. Localisation changes the full user experience.

Localisation includes:

• Currency

• Date formats

• Address formats

• Category names

• Spelling

• Legal notices

• Local terminology

• Measurement units

Conclusion

A multi-market application needs a clear separation between shared application logic and country-specific configuration.

A practical architecture should:

• Resolve the market from the URL

• Store market settings centrally

• Keep language and country separate

• Format prices using locale-aware tools

• Adapt address forms

• Filter categories by market

• Validate country data on the server

• Generate consistent canonical URLs

• Respect manual country selection

This approach makes it easier to add new markets without duplicating the entire application.

The examples in this article are based on lessons from developing a real multi-country classifieds project.

Disclosure: I am building NPATI.

Project example:

https://www.npati.com