Back to Academy
Phase 9: Internationalization & Localization 路 Lesson 1Advanced

Shopify Markets vs. separate stores - the architecture decision

Lesson 61 of 813 min read

Phase 1 introduced Shopify Markets as the mental model; this phase starts where the real decisions live. The first and largest: one store serving all countries through Markets, or separate Shopify stores per country/region? Brands relitigate this constantly - usually because they inherited one answer and feel the friction - so here's the trade-off space laid out honestly.

What one store with Markets buys you

One catalog, one integration stack, one team workflow. Every product exists once; enrichment, apps, theme work, and analytics happen once; the transformation layers from Phase 7 project per market. Domain authority concentrates - every market's content strengthens one domain (the subfolder argument from Phase 1, now with its full weight: a German market at /de-de/ inherits the authority your whole store has earned, versus a fresh .de domain starting from zero). Operational overhead scales sub-linearly with markets: opening market five is configuration, not construction.

The costs: per-market flexibility has ceilings. Pricing is per-market but the catalog structure is shared - you can include/exclude products per market but not restructure them; checkout and functional customization per market is limited; apps vary in Markets-awareness (an app that isn't market-aware applies one behavior everywhere - audit this before, not after); and organizationally, one store means one release surface - a mistake ships to every market simultaneously.

What separate stores buy you

Full per-country freedom: independent catalogs, pricing logic, apps, themes, checkout flows, even brand expressions; genuinely local operations (a Japanese store run by a Japanese team on its own release cycle); clean blast-radius isolation. The costs are the mirror image: N stores means N catalogs to keep synchronized (the divergence problem from Phase 7's hub-and-spoke lesson, at store scale - this is where PIM-class tooling stops being optional), N integration stacks, N SEO efforts building N separate domains' authority, and every catalog improvement paid N times. The tax is permanent and compounds with catalog size and change velocity.

The decision grid, and the hybrid reality

Default to Markets when: your catalog is substantially shared across markets, your team is centralized, your differentiation needs are pricing/language/currency-level, and your market count ambition is high. Default to separate stores when: a market needs a genuinely different business (distinct catalog majority, local fulfillment/legal entity with different requirements, local team autonomy), or a single market is large enough to justify its own operational universe (the classic: everything on Markets except a standalone US or Japan store). That hybrid is common and legitimate - the mistake isn't either architecture, it's unchosen architecture: separate stores that exist because of history, paying the synchronization tax for flexibility nobody uses. If that audit describes you, consolidation onto Markets is usually the highest-ROI infrastructure project available - and the rest of this phase assumes the Markets architecture while flagging where separate-store logic differs.