How would you architect a multi-site, multi-locale SFCC build?

Long Answer

A robust multi-site, multi-locale Salesforce Commerce Cloud implementation with SFRA hinges on one codebase, well-governed data, and repeatable operations. The goal is to let each site express brand and locale differences through configuration, Page Designer, and site preferences while preventing code fragmentation.

1) Cartridge layering and code governance
Adopt a single code version. Order the cartridge path left-to-right with first-match wins:
app_custom_<brand> : int_<systems> : app_storefront_base : bm_<tools>
Place brand-specific overrides in app_custom_<brand> (controllers, pipelines, ISML, hooks). Keep integration logic isolated in int_* cartridges (payments, tax, search). Avoid per-site forks; instead branch behavior by site or locale via preferences, resource bundles, and hook implementations. Enforce linting, unit tests, and metadata validation in continuous integration, and release through code version promotion to keep environments aligned.

2) Multi-site structure and data domains
Create a master catalog for products, variations, attributes, and images that all sites share. For site-specific merchandising, use site catalogs that reference the master products but allow local categories and sort rules. Manage price books per currency or tier and link them to sites via the site’s price book assignment. Maintain inventory lists per region or distribution center and bind lists to sites as needed.

3) Promotions, campaigns, and customer groups
Define promotions in campaigns that can be global or site scoped. Reuse qualifiers and coupon sets across locales where practical, but keep messages, disclaimers, and legal copy in resource bundles so translation is managed outside code. Use customer groups to target segments consistently across sites and bind promotions to groups rather than duplicating rules.

4) Page Designer for content velocity
Publish shared Page Designer components and templates from a dedicated library cartridge, for example app_pd_<brand>. Components accept configuration for imagery, copy, and behavior; keep business logic minimal and move dynamic data access into server-side controllers or data providers. Localize via content assets and resource bundles, not by cloning components per locale. For multi-site reuse, store common content in a shared content library and site-specific assets in site libraries.

5) Site preferences and custom attributes
Drive differences through site preferences: payment methods, checkout flow flags, default locales, locale mapping, search settings, and feature toggles. When you need per-site behavior, model custom site preference attributes via System Object Definitions. Keep fallbacks sensible so global defaults apply where a site has no override. Expose toggles to Page Designer components through configuration fields to avoid code changes for content variations.

6) Localization and resource strategy
Enable multiple locales per site and map each locale to the correct currency, price book, and inventory view. Use resource bundles for labels, errors, and promotional text. For product content, manage translations in the master catalog and replicate to sites; for legal copy and marketing text, use content assets per locale. Maintain consistent URL rules and locale prefixes to support search engine optimization and navigation.

7) Data flows, replication, and jobs
Treat Staging as the source of truth for data and Production as the live runtime. Use replication for catalogs, price books, promotions, content libraries, Page Designer assets and pages, customer groups, and search indexes. Schedule replication waves that respect dependencies: catalogs and price books first, then inventory, then promotions and campaigns, then content and Page Designer pages, and finally search index replication. Use Business Manager jobs for imports (feeds, product updates), image processing, and cache invalidation. Keep site code synchronized by promoting the same code version across all sites; never deploy per-site code versions.

8) Caching, performance, and search
Configure page cache rules with vary by site, locale, and customer group where necessary. Use slot caching for shared regions and keep Page Designer components cache friendly. For search, centralize synonyms, ranking rules, and searchable attributes where possible, then override per locale only when data proves the need. Rebuild indexes after large imports and as part of the replication schedule.

9) Security, permissions, and governance
Restrict Business Manager roles by site to avoid accidental edits across brands. Use OCAPI and Shop API configurations scoped per site with least privilege. Track changes to content, promotions, and price books via audit logs and approvals where required. Document cartridge extension points, hook usage, and preference contracts so new sites onboard without divergence.

10) Non-production parity and release discipline
Mirror the site matrix in Development and Staging. Use identical cartridge paths and preference sets. Seed realistic data volumes for load tests. Release changes through a calendar that coordinates data replication, index rebuilds, and code version activation, with automated smoke tests per site and locale to catch regressions before promotion.

This approach delivers a multi-site SFCC architecture where one codebase powers many storefronts, Page Designer enables rapid content, site preferences express differences, and carefully scheduled replication keeps catalogs, promotions, and content synchronized without code drift.

‍

Table

‍

Common Mistakes

Cloning cartridges per site and drifting from app_storefront_base. Baking brand logic into templates instead of using site preferences and resource bundles. Duplicating Page Designer components per locale rather than driving content via configuration. Mixing master and site catalog responsibilities, which breaks replication and search. Assigning global price books and then overriding prices ad hoc per product. Replicating promotions before catalogs or price books, causing broken eligibility. Running different code versions per site. Using broad OCAPI permissions and shared Business Manager roles that allow cross-site edits.

‍

Sample Answers (Junior / Mid / Senior)

Junior:
“I would keep one code version. I would layer app_custom_<brand> before app_storefront_base and use site preferences and resource bundles for differences. I would store products in a master catalog and use site catalogs for categories. I would use Page Designer templates from a shared library and replicate data from Staging to Production.”

Mid:
“My SFCC architecture uses a single codebase with app_custom_<brand>, integration cartridges, and a shared Page Designer library. I map locales to currencies and price books, and I drive promotions through campaigns and customer groups. Replication runs in waves: catalogs and price books, inventory, promotions, content, then search. Preferences and custom attributes express site behavior without code forks.”

Senior:
“I enforce cartridge layering and hook-based overrides, never per-site forks. Master catalog data is canonical; sites vary via site catalogs, price books, inventory lists, and localized resource bundles. Page Designer components are configuration-driven and cache friendly. Replication is scheduled with dependency order and smoke checks. OCAPI and Business Manager roles are least privilege. One code version powers all sites to eliminate drift.”

‍

Evaluation Criteria

Look for a Salesforce Commerce Cloud architecture that uses one code version, disciplined cartridge layering, and hook-based overrides. Strong answers separate master versus site catalogs, attach price books and inventory by site, and localize via resource bundles and content libraries. They use a shared Page Designer library for reusable templates, site preferences and custom attributes for behavior, and a staged replication plan that respects dependencies. Red flags include per-site code versions, duplicated components per locale, promotions that do not align with catalog and price replication, and vague governance of OCAPI permissions and Business Manager roles.

‍

Preparation Tips

Create a sandbox with two sites and two locales each. Build app_custom_<brand> on top of SFRA and add one int_* cartridge. Implement three Page Designer components with configuration fields and resource bundle strings. Model a master catalog with shared products, two site catalogs with different category trees, and separate price books per currency. Define two campaigns and reuse qualifiers via customer groups. Add custom site preferences for checkout options and map locales to currencies. Script a replication sequence and include an index rebuild. Add smoke tests that hit home, search, product detail, and checkout for each site and locale after replication and code activation.

‍

Real-world Context

A retailer ran four regional sites from one SFRA codebase but initially cloned cartridges per region. Consolidating into a single app_custom_<brand> with hook overrides removed code drift and cut release time. Promotions failed after imports until replication was ordered: catalogs and price books first, then promotions and content, then indexing. A shared Page Designer library allowed brand teams to launch campaigns without development work, while site preferences toggled regional payment methods. Least-privilege OCAPI settings and site-scoped Business Manager roles prevented accidental cross-site edits. The result was faster content, predictable promotions, and stable multi-locale storefronts.

‍

Key Takeaways

• Keep a single code version with strict cartridge layering and hook-based overrides.
  
• Use a master catalog plus site catalogs, site price books, and inventory lists.
  
• Centralize Page Designer templates in a shared library; localize via resources and content assets.
  
• Drive behavior through site preferences and custom attributes, not code forks.
  
• Schedule dependency-aware replication waves and rebuild search indexes.
  
  

Practice Exercise

Scenario:
You are launching three SFCC sites (United States, United Kingdom, Germany) on SFRA. All share products, but categories, prices, promotions, and content differ by market. Marketing requires Page Designer autonomy and fast campaign rollouts without developer changes.

Tasks:

1. Define the cartridge path and what lives in app_custom_<brand>, int_*, and the Page Designer library cartridge. Explain how hooks and resource bundles avoid per-site forks.
   
2. Model catalogs: a master catalog for products and images, three site catalogs for categories. Map locales to currencies and assign price books per site.
   
3. Specify promotions with campaigns and customer groups. Show how you will localize disclaimers and legal copy without cloning rules.
   
4. List site preferences and custom attributes that control payments, search, and feature flags per site.
   
5. Design Page Designer components with configuration fields and content library strategy (shared versus site specific).
   
6. Propose a replication schedule from Staging to Production in dependency order, including search index rebuilds and cache invalidation.
   
7. Define OCAPI and Shop API settings per site with least privilege and site-scoped Business Manager roles.
   
8. Outline smoke tests that validate home, search, product detail, add to cart, and promotion application across all sites and locales after activation of a new code version.
   
   

Deliverable:
A concise plan and checklist that demonstrates a maintainable, synchronized multi-site SFCC architecture with SFRA, Page Designer, site preferences, and reliable replication without code drift.