Skip to content

Instantly share code, notes, and snippets.

@harryneopotter

harryneopotter/Chal.json

Created March 17, 2026 05:08
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save harryneopotter/9023964a57933c6c43dcd92e1dfdf09c to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save harryneopotter/9023964a57933c6c43dcd92e1dfdf09c to your computer and use it in GitHub Desktop.
Download ZIP
Chak-json
Raw
Chal.json
{
"topics": [
{
"name": "SFRA Internals",
"core_concepts": [
"SFRA is a modular reference storefront built around the app_storefront_base cartridge and server module.[1][2]",
"Implements a variant of MVC where controllers prepare view models consumed by ISML templates.[3][2]",
"Cartridge overlay model supports base, plugin, LINK, and custom cartridges layered via the cartridge path.[1][2]",
"Business logic is centralized in controllers and models rather than templates, improving testability.[3][2]",
"Hooks and middleware enable extension points for payments, checkout, and personalization.[1][2]",
"Designed as mobile‑first with responsive UX patterns derived from large‑scale storefront analysis.[3][4]"
],
"senior_explanation": "SFRA replaces legacy SiteGenesis with a modular, data‑driven reference architecture that cleanly separates storefront concerns into cartridges, controllers, models, and ISML views, enabling overlay customization instead of template cloning.[3][2] Core commerce flows live in app_storefront_base, while optional capabilities and third‑party integrations ship as plug‑in and LINK cartridges that you stack and override via cartridge path ordering.[1][2] Controllers orchestrate script APIs, build view models, and delegate rendering to views, making it easier to unit test and evolve business logic without breaking markup.[3][2] The design is explicitly optimized for mobile and modern browser behavior, giving architects a safer baseline than SiteGenesis while still requiring disciplined extension patterns to avoid regressions.[3][4]",
"architecture_patterns": [
"Base‑plus‑overlay: keep app_storefront_base pristine and implement custom behavior in separate overlay cartridges.[1][2]",
"Feature isolation via plugin cartridges (for example, gift registry, in‑store pickup) that can be added or removed per site.[1][2]",
"Hook‑driven customization for payments, tax, and integrations to avoid hard‑coding providers in core flows.[1][2]",
"MVC pattern with controllers creating view models that shield templates from platform object structures.[3][2]",
"Shared base cartridges across multi‑site setups with site‑specific cartridges only where divergence is required.[1][2]"
],
"integration_patterns": [
"Use LINK cartridges for certified integrations to payment, tax, ratings, and shipping providers rather than building from scratch.[2][5]",
"Expose SFRA server‑side data via OCAPI or SCAPI for headless or external channel consumption.[6][7]",
"Implement hook‑based adapters in integration cartridges to plug into SFRA checkout and customer lifecycle events.[1][2]",
"Leverage Page Designer‑aware cartridges when integrating CMS or experience management solutions.[8][9]"
],
"performance_considerations": [
"Minimize logic in ISML templates; keep heavy computation in controllers and back‑end services.[3][2]",
"Design controllers to be cache‑friendly, respecting application server and CDN caching strategies.[10][11]",
"Avoid deep cartridge path chains that increase script resolution overhead and complicate overrides.[1][2]",
"Use custom caches judiciously for expensive lookups invoked from SFRA controllers.[12][13]"
],
"security_considerations": [
"Rely on SFRA middleware for HTTPS enforcement and authentication checks on sensitive pipelines.[14][15]",
"Ensure all user‑supplied data rendered by ISML is properly encoded to prevent XSS.[16]",
"Apply B2C Commerce security best practices and OWASP‑aligned guidelines when extending controllers and forms.[17][18][16]",
"Avoid exposing internal object identifiers without additional authorization checks in SFRA flows.[16][14]"
],
"common_pitfalls": [
"Modifying app_storefront_base directly instead of extending via overlay cartridges, blocking clean upgrades.[1][2]",
"Mixing heavy business logic into ISML, reducing maintainability and test coverage.[3][2]",
"Duplicating SiteGenesis patterns such as template cloning rather than using SFRA’s extension model.[3]",
"Breaking hook contracts when customizing LINK or plugin cartridges, causing fragile integrations.[2][5]"
],
"real_world_examples": [
"Global fashion brand replatforming from SiteGenesis to SFRA using base cartridge plus regional overlay cartridges.[3][4]",
"Payment provider delivering an SFRA‑compatible LINK cartridge that plugs into SFRA checkout hooks.[2][5]",
"Retailer enabling mobile‑first UX improvements by leveraging SFRA’s responsive templates and controllers.[3][4]"
],
"interview_questions": [
{
"question": "Explain how cartridge overlays and hook extensions should be used to customize SFRA without touching app_storefront_base.",
"difficulty": "mid"
},
{
"question": "How does SFRA’s MVC pattern differ from SiteGenesis, and why does it matter for large teams?",
"difficulty": "mid"
},
{
"question": "Design a strategy to share SFRA base code across multiple brands while allowing controlled divergence per site.",
"difficulty": "senior"
},
{
"question": "Where would you enforce authentication and authorization in SFRA for a new account management feature?",
"difficulty": "mid"
}
]
},
{
"name": "Cartridge Architecture & Resolution",
"core_concepts": [
"Cartridges are deployment units that package code and data for B2C Commerce storefronts and integrations.[2][5]",
"Cartridge path order in Business Manager determines which implementation wins when multiple cartridges define the same resource.[1][2]",
"Types include base, plugin, LINK, and custom cartridges, often combined into stacks per site.[1][2][5]",
"Resolution applies to scripts, pipelines, templates, static assets, and configuration resources.[1][2]",
"Shared cartridges can be mapped to multiple sites, while site‑specific cartridges hold unique behavior.[1][9]",
"Page Designer, SFRA, and LINK solutions each ship as cartridges that must be placed correctly in the stack.[2][8][5]"
],
"senior_explanation": "Cartridges define the modular deployment and override model for SFCC, with each site’s behavior emerging from the ordered cartridge path that the runtime traverses when resolving scripts, templates, and metadata.[1][2] Base cartridges contain core features, while plugin and LINK cartridges add optional or third‑party capabilities, and custom cartridges provide project‑specific overlays layered above them.[2][5] Resolution precedence is purely positional, so architects must design consistent stacks across environments and sites, ensuring that shared cartridges stay low in the stack and site‑specific overrides sit above.[1][9] Poor cartridge design leads to brittle overrides, upgrade pain, and hidden coupling, especially when multiple teams contribute cartridges to the same instance.[2][5]",
"architecture_patterns": [
"Core‑shared‑site layering: core SFRA and platform cartridges, shared business cartridges, then site‑specific cartridges at the top.[1][2][9]",
"Dedicated integration cartridges for each external system (payment, tax, OMS) to isolate vendor‑specific logic.[2][5]",
"Read‑only base and plugin cartridges with all customizations in overlay cartridges owned by the implementation team.[1][2]",
"Separate Page Designer cartridges for page/component types and UI assets, shared across multiple sites.[8][9]"
],
"integration_patterns": [
"Ship third‑party integrations as LINK cartridges that plug into SFRA hooks and jobs without editing base code.[2][5]",
"Use organization‑level cartridges for cross‑site concerns like SSO, logging, and monitoring.[9][19]",
"Align OCAPI and SCAPI customizations with dedicated integration cartridges to keep storefront cartridges focused on UX.[6][7][12]",
"Design separate cartridges for OMS or ERP integrations that participate in jobs and order lifecycle hooks.[20][21][22]"
],
"performance_considerations": [
"Keep the cartridge path as short and flat as feasible to reduce lookup overhead for each resolved resource.[1][2]",
"Avoid unnecessary duplication of assets and templates across cartridges to limit deployment size and cache churn.[10][11]",
"Centralize expensive utilities in shared cartridges to reuse caching and avoid repeated implementations.[12][13]",
"Ensure cartridge mapping and path are identical across staging and production to prevent cache fragmentation.[10][23]"
],
"security_considerations": [
"Centralize security‑sensitive code (auth, encryption helpers, header policies) into vetted shared cartridges.[17][18][16]",
"Enforce HTTPS and secure headers in a shared cartridge to guarantee consistent behavior across all sites.[18][16][15]",
"Limit access to cartridges that contain secrets or integration credentials and avoid embedding secrets directly in code.[16]",
"Ensure LINK and partner cartridges comply with B2C Commerce security best practices before adding them to the stack.[17][18][5]"
],
"common_pitfalls": [
"Random or inconsistent cartridge ordering between environments causing non‑reproducible bugs.[1][9]",
"Editing vendor or base cartridges, making upgrades and security patches difficult.[1][2][5]",
"Duplicating the same functionality across multiple cartridges instead of reusing shared components.[2][5]",
"Site‑specific cartridges leaking behavior into other sites because of shared cartridge mappings.[9]"
],
"real_world_examples": [
"Multi‑brand retailer running shared SFRA and Page Designer cartridges with brand‑specific cartridges per site.[2][8][9]",
"Payment provider delivering separate LINK cartridges for core services and SFRA storefront integration.[24][5]",
"Global implementation where OMS, tax, and search each have their own integration cartridges at the organization level.[21][5]"
],
"interview_questions": [
{
"question": "Describe how cartridge resolution works when two cartridges define the same controller and template.",
"difficulty": "mid"
},
{
"question": "How would you structure cartridges for a multi‑brand, multi‑site rollout sharing 80% of code?",
"difficulty": "senior"
},
{
"question": "What risks arise from changing cartridge order between staging and production?",
"difficulty": "mid"
},
{
"question": "When would you introduce a new shared cartridge versus extending an existing one?",
"difficulty": "senior"
}
]
},
{
"name": "OCAPI Data API",
"core_concepts": [
"OCAPI Data API manages merchant resources such as catalogs, coupons, customer lists, jobs, and content.[6]",
"Access is via HTTP with JSON or XML payloads and versioned resource URLs.[6][25]",
"Primarily used for back‑office and integration use cases, not high‑volume shopper traffic.[6][25]",
"Authorization uses OAuth 2.0 with client permissions configured per instance and per site.[6][25][26]",
"Client permissions and resource settings are managed via OCAPI settings JSON in Business Manager.[26]",
"Supports features like property selectors, queries, batch requests, and optimistic locking with resource states.[25]"
],
"senior_explanation": "The OCAPI Data API is SFCC’s administrative surface for programmatic management of business objects, designed for controlled back‑office integrations rather than real‑time shopper flows.[6][25] Architects configure OCAPI settings to define which clients can access which resources at global or site scope, combining OAuth 2.0, client scopes, and per‑resource configuration.[6][25][26] Data API capabilities such as queries, property selection, and batch requests allow efficient synchronization of catalogs, prices, content, and customer data with external PIM, CRM, or ERP systems.[25] Salesforce now recommends favoring SCAPI for new work, but OCAPI Data remains critical where features are not yet covered or where existing operational integrations are stable and heavily customized.[25][27]",
"architecture_patterns": [
"Use OCAPI Data for scheduled or event‑driven integrations that modify catalogs, prices, and customer data.[6][25]",
"Centralize OCAPI configuration in source control as JSON and deploy via jobs or CI to keep environments aligned.[25][26][23]",
"Limit Data API access to secure network locations (middleware, MDM, ERP) rather than browsers.[6][25]",
"Pair Data API writes with platform jobs for bulk operations and post‑processing.[28][20]"
],
"integration_patterns": [
"PIM to SFCC: push catalog structures, attributes, and digital assets via Data API.[6][25]",
"ERP to SFCC: sync price books, tax tables, and inventory snapshots using authorized Data clients.[6][25]",
"CRM or CDP: update customer profiles, segments, and lists based on external engagement signals.[6][25]",
"Order export from SFCC to OMS/ERP using jobs plus Data API reads where applicable.[20][21][22]"
],
"performance_considerations": [
"Use batch requests to reduce HTTP overhead when performing many small related operations.[25]",
"Restrict properties returned using selectors and queries to minimize payload size.[25]",
"Avoid using Data API for chatty, synchronous shopper flows; favor SCAPI or OCAPI Shop instead.[6][7][25]",
"Align Data API operations with jobs and off‑peak windows to reduce impact on storefront traffic.[28][20]"
],
"security_considerations": [
"Harden OCAPI client permissions by granting minimum required access per resource and site.[25][26][18]",
"Use OAuth 2.0 securely, rotating client secrets and restricting where clients can be used.[6][25][17]",
"Configure CORS and caching cautiously to prevent data exposure through misconfigured proxies.[25][26][16]",
"Mask sensitive fields like inventory thresholds using resource‑specific settings.[26]"
],
"common_pitfalls": [
"Using highly permissive OCAPI client configurations that expose admin operations to unintended consumers.[25][26][18]",
"Treating Data API as a real‑time channel for shopper interactions, creating latency and scalability issues.[6][25]",
"Forgetting to synchronize OCAPI settings between environments, causing unexpected 403 or behavior differences.[26][23]",
"Returning full resources instead of selected properties, inflating network usage.[25]"
],
"real_world_examples": [
"PIM system exporting nightly catalog updates into SFCC using OCAPI Data and scheduled jobs.[6][25][20]",
"ERP pushing updated price books and promotion data to B2C Commerce via secured Data API clients.[6][25][21]",
"CDP enriching customer profiles in B2C Commerce for targeted marketing lists.[6][25]"
],
"interview_questions": [
{
"question": "When would you choose OCAPI Data over SCAPI Admin for an integration?",
"difficulty": "senior"
},
{
"question": "How do OCAPI settings JSON and client permissions work together to secure Data API access?",
"difficulty": "mid"
},
{
"question": "What techniques can you use to reduce the performance impact of bulk imports via OCAPI Data?",
"difficulty": "mid"
},
{
"question": "How would you safely expose limited catalog data from Data API to a third‑party tool?",
"difficulty": "senior"
}
]
},
{
"name": "OCAPI Shop API",
"core_concepts": [
"OCAPI Shop API exposes shopper‑facing resources such as products, baskets, and orders over HTTP.[6][25]",
"Designed as a stateless API secured via OAuth and JSON Web Tokens for session handling.[6][25]",
"Commonly used for custom storefronts, mobile apps, or client‑side integrations predating SCAPI.[6][25][29]",
"Supports features like search, product detail, basket operations, and checkout endpoints.[6]",
"Caching headers and OCAPI settings influence how responses can be cached at proxies and clients.[25][26]",
"Salesforce recommends SCAPI for most new projects, but OCAPI Shop remains widely used.[25][27]"
],
"senior_explanation": "The OCAPI Shop API is the legacy but still‑supported shopper‑facing API that underpins many existing custom storefronts and mobile experiences on B2C Commerce.[6][25][29] It provides REST‑like endpoints for catalog browsing, pricing, baskets, and orders, using bearer tokens and JSON Web Tokens for stateless authentication.[6][25] Shop API behavior is shaped by OCAPI settings, which control client permissions, personalization, localization, and caching characteristics.[25][26] While SCAPI is now the preferred API for new shopper experiences, senior engineers must understand Shop API to maintain or gradually migrate existing sites without disrupting revenue.[25][29][27]",
"architecture_patterns": [
"Single‑page applications consuming Shop API directly with a lightweight storefront running outside SFCC.[6][25]",
"Hybrid SFRA plus Shop API patterns where certain flows (for example, mobile app) use Shop API while web uses server‑rendered SFRA.[6][29]",
"Use of proxy or BFF layers in front of Shop API to normalize data and implement cross‑cutting concerns.[25][10][12]",
"Gradual migration where high‑impact flows move to SCAPI while legacy flows remain on Shop API.[7][25][29]"
],
"integration_patterns": [
"Mobile apps consuming Shop API for catalog and basket operations.[6][25]",
"In‑store kiosks integrating with Shop API for real‑time product data and availability.[6][25]",
"Custom CS tools using Shop API in combination with Data API for unified customer views.[6][25][30]",
"Payment Service Provider integrations using Shop API interactions for Customer Service Center operations.[30]"
],
"performance_considerations": [
"Use client‑side and proxy caching where safe; align with OCAPI caching guidelines and headers.[25][10]",
"Avoid excessive expansion of linked resources in a single Shop request to keep latency low.[25][12]",
"Batch client‑side operations where possible instead of many small sequential calls.[25]",
"Monitor OCAPI latency budgets relative to recommended response time targets for API traffic.[11]"
],
"security_considerations": [
"Configure least‑privilege OCAPI Shop client permissions and avoid exposing admin capabilities.[25][26][18]",
"Enforce HTTPS, secure cookies, and strict token handling when using Shop API from browsers.[25][16][15]",
"Apply OWASP‑aligned input validation and output encoding on any custom BFFs consuming Shop API.[17][18][16]",
"Carefully configure CORS when exposing Shop API directly to JS applications.[25][16]"
],
"common_pitfalls": [
"Leaking sensitive data (for example, stock levels) by misconfiguring Shop API resource settings.[26]",
"Using Shop API heavily for back‑office operations that are better served by Data or SCAPI Admin APIs.[6][7][25]",
"Over‑personalizing responses so that upstream caching becomes ineffective, reducing scalability.[25][10][12]",
"Locking into Shop API data shapes in new builds instead of adopting SCAPI early.[7][25][29]"
],
"real_world_examples": [
"Legacy mobile storefront using OCAPI Shop for all shopper operations.[6][25][29]",
"Customer Service Center integration that updates payment methods through Shop API and PSP hooks.[30]",
"Retailer progressively migrating checkout flows from Shop API to SCAPI Shopper APIs.[7][29]"
],
"interview_questions": [
{
"question": "Compare OCAPI Shop and SCAPI Shopper APIs in terms of capabilities and recommended usage.",
"difficulty": "mid"
},
{
"question": "How do OCAPI settings influence security and caching for Shop API clients?",
"difficulty": "senior"
},
{
"question": "What migration strategies would you use to move an existing Shop‑based head to SCAPI?",
"difficulty": "senior"
},
{
"question": "When is it acceptable to expose Shop API directly to a browser‑based SPA?",
"difficulty": "mid"
}
]
},
{
"name": "SCAPI",
"core_concepts": [
"SCAPI (B2C Commerce API) is a modern RESTful API stack for shopper and admin use cases.[7][31]",
"Provides Shopper APIs for customer‑facing functions and SCAPI Admin APIs for merchant tools and back‑office apps.[7][32]",
"Shopper APIs are secured via Shopper Login and API Access Service (SLAS) with OAuth2 and JWTs.[7][32][33]",
"Admin APIs are secured via Account Manager and scoped API clients.[7][32][33]",
"Salesforce recommends SCAPI for new projects and major refactors instead of OCAPI.[7][25][27]",
"SCAPI is designed for high‑scale usage with headless and composable storefronts, including PWA Kit.[7][31][34]"
],
"senior_explanation": "SCAPI is the strategic API surface for B2C Commerce, separating high‑scale Shopper APIs from Admin APIs and aligning authorization with SLAS and Account Manager respectively.[7][32][33] Shopper APIs handle browsing, basket, and checkout scenarios with JWT‑based authentication and are optimized for use by PWAs, native apps, and custom storefronts.[7][32][31] Admin APIs cover product, price, inventory, and customer management for trusted back‑office clients, using Account Manager scopes to enforce least privilege.[7][32][33] SCAPI adds performance‑oriented features like controlled resource expansion, caching guidance, and size limits while coexisting with OCAPI for features not yet ported, making coexistence and phased migration key responsibilities for senior engineers.[7][25][12]",
"architecture_patterns": [
"Headless architectures where PWA Kit or custom frontends consume SCAPI Shopper APIs and call Admin APIs via secure services.[7][31][34]",
"BFF (Backend‑for‑Frontend) services mediating between UI clients and SCAPI to centralize logic and security.[31][12][33]",
"Coexistence layer where legacy OCAPI integrations are maintained while new capabilities use SCAPI.[7][25][29]",
"Composable micro‑frontend strategies using SCAPI data as the contract between domains.[7][31]"
],
"integration_patterns": [
"PWA Kit storefront using Shopper APIs for catalog, basket, and checkout.[7][31][34]",
"Custom merchant tools or admin portals built on SCAPI Admin APIs for catalog and order management.[7][32]",
"3rd‑party systems (OMS, ERP, CDP) integrating via SCAPI Admin instead of Data API where feature coverage exists.[7][27][12]",
"Use of Commerce SDK clients that wrap SCAPI with built‑in caching and retries.[31][35]"
],
"performance_considerations": [
"Use expand parameters carefully because expanded resources affect cache hit rates and payload sizes.[12]",
"Leverage Commerce SDK caching (in‑memory or Redis) to reduce repeated SCAPI calls.[35][12]",
"Avoid unnecessary intermediate caches that ignore personalization signals and break correctness.[10][12]",
"Observe documented SCAPI limits on request and response sizes and tune clients accordingly.[7][12]"
],
"security_considerations": [
"Ensure SLAS flows and Account Manager clients are configured with minimal scopes and strong secrets.[7][32][33]",
"Secure custom heads and BFFs following general web security best practices, since Salesforce only secures SCAPI endpoints.[16][33]",
"Respect rate limits and DoS protections and design clients to handle throttling gracefully.[33]",
"Use HTTPS everywhere and enforce secure cookie and header policies around SCAPI usage.[18][16][33]"
],
"common_pitfalls": [
"Treating SCAPI responses as fully cacheable without considering personalization and auth context.[12][33]",
"Mixing Admin API calls directly into browser clients instead of server‑side services.[7][32][33]",
"Overusing expand parameters leading to high latency and cache misses.[12]",
"Ignoring SLAS best practices, resulting in brittle token handling and security gaps.[7][33]"
],
"real_world_examples": [
"Composable Storefront architectures built with PWA Kit and SCAPI for multi‑site commerce.[31][34][33]",
"Retailers replacing OCAPI‑based mobile apps with SCAPI‑backed experiences to improve performance.[7][29][12]",
"Headless integrations where SCAPI Admin feeds product and inventory data into external systems.[7][27]"
],
"interview_questions": [
{
"question": "Explain the security and usage differences between SCAPI Shopper APIs and SCAPI Admin APIs.",
"difficulty": "mid"
},
{
"question": "How would you design a migration plan from an OCAPI‑based storefront to SCAPI and PWA Kit?",
"difficulty": "senior"
},
{
"question": "What are the implications of SCAPI’s expand parameter on caching and scalability?",
"difficulty": "senior"
},
{
"question": "When would you still use OCAPI instead of SCAPI on a modern implementation?",
"difficulty": "mid"
}
]
},
{
"name": "Page Designer Architecture",
"core_concepts": [
"Page Designer lets merchants build pages visually using reusable page and component types defined by developers.[36][8][37]",
"Developers create page/component metadata and rendering scripts in dedicated Page Designer cartridges.[8][9]",
"Components are designed to be self‑contained, with their own styling and configurable attributes.[9]",
"Page and component instances are stored as data, enabling reuse across locales, devices, and segments.[36][8]",
"Custom attribute editors run in sandboxed iframes communicating with the host via a messaging channel.[8]",
"Supports scheduling, targeting, and localization of pages and components without code changes.[38][36][37]"
],
"senior_explanation": "Page Designer separates page composition from code by letting developers define typed building blocks while merchandisers assemble localized, scheduled experiences through Business Manager.[36][8][37] Architecture‑wise, developers contribute cartridges that contain meta definitions, rendering logic, and supporting UI assets, while the platform persists page and component instances as content data that can be reused across pages and sites.[8][9] Components are expected to be self‑contained, with robust defaults and careful versioning to avoid breaking existing content when definitions evolve.[9] A sandboxed attribute‑editor framework using iframes and a message channel allows safe customization of the Page Designer UI without risking cross‑component interference.[8][39]",
"architecture_patterns": [
"Dedicated experience cartridges: one for meta definitions and scripts, another for UI assets and helpers.[8][9]",
"Shared libraries of page/component types used across multiple sites mapped to common cartridges.[8][9]",
"Black‑box component design where each component manages its own styling and dependencies.[9]",
"Integration of Page Designer rendering into SFRA via experience utilities and page scripts.[8][40]"
],
"integration_patterns": [
"Using Page Designer components to surface CMS content, including Salesforce CMS, on storefront pages.[39][41]",
"Implementing components that integrate with recommendation engines, search, or personalization services.[8][37]",
"Sharing Page Designer libraries across multi‑site catalogs so common layouts stay consistent.[9][42]",
"Embedding analytics and A/B testing hooks inside components for experience optimization.[8][37]"
],
"performance_considerations": [
"Design components to be cache‑friendly and avoid heavy server logic during render.[10][11][9]",
"Minimize client‑side JS and third‑party tags loaded per component to prevent page bloat.[10][9]",
"Reuse layouts and assets across pages to maximize CDN effectiveness.[10][8]",
"Plan component granularity carefully to avoid deep nesting that complicates rendering.[9]"
],
"security_considerations": [
"Ensure attribute editors validate and encode input to prevent XSS in rendered pages.[8][16]",
"Avoid exposing sensitive data through component attributes or Page Designer metadata.[9][18]",
"Follow general B2C security best practices for authentication, HTTPS, and secure headers on Page Designer pages.[18][16][15]",
"Treat custom editor iframes as untrusted and constrain communication to well‑defined messages.[8][16]"
],
"common_pitfalls": [
"Changing component meta definitions incompatibly after content is created, breaking existing instances.[9]",
"Allowing sites that share libraries to drift in cartridge mappings, causing validation errors.[9]",
"Building components that depend on context‑specific styling instead of behaving as self‑contained blocks.[9]",
"Overusing Page Designer for transactional flows (for example, checkout) instead of content‑centric experiences.[36][8]"
],
"real_world_examples": [
"Merchandisers building campaign landing pages with localized hero and grid components without developer changes.[36][37]",
"Shared Page Designer component library driving consistent branding across multiple regional sites.[8][9]",
"CMS content from Salesforce CMS rendered through dedicated Page Designer components.[39][41]"
],
"interview_questions": [
{
"question": "How would you design Page Designer components so multiple sites can share them safely?",
"difficulty": "senior"
},
{
"question": "What are the risks of changing Page Designer meta definitions after pages are live?",
"difficulty": "mid"
},
{
"question": "When is Page Designer an appropriate solution versus content slots or SFRA templates?",
"difficulty": "mid"
},
{
"question": "How do custom attribute editors integrate with the Page Designer host, and what security concerns arise?",
"difficulty": "senior"
}
]
},
{
"name": "Multi-site & Multi-locale Architecture",
"core_concepts": [
"B2C Commerce is structured as an organization containing one or more sites (storefronts).[[43][42]]",
"Locales and currencies are configured at organization and site levels in Business Manager.[43][42]",
"Locales affect products, content, URLs, taxation, and system objects across the platform.[43][42]",
"Sites can share cartridges, catalogs, content libraries, and Page Designer libraries, or use separate ones.[8][9][42]",
"Locale fallback and shared data strategies determine behavior when content is missing in a locale.[43][42][44]",
"Composable Storefront and PWA Kit support multiple sites and locales via configuration files and aliases.[34]"
],
"senior_explanation": "Multi‑site architecture lets organizations model brands, regions, or channels as separate sites while sharing core code, catalogs, or content where appropriate.[43][42][45] Locale configuration spans organization and site levels, affecting currencies, date formats, URLs, and localized product and content data.[43][42] Architects must decide which assets are global versus site‑specific and design cartridge mappings, catalogs, and libraries accordingly to avoid drift and duplication.[8][9][45] In headless scenarios, PWA Kit’s configuration maps Business Manager sites and locales to URL structures and domains, enabling multi‑site experiences with a single codebase.[34]",
"architecture_patterns": [
"One org, many sites: each brand/region as a separate site sharing core cartridges and sometimes catalogs.[43][42][45]",
"Shared content and Page Designer libraries across sites with local overrides where needed.[8][9][42]",
"Locale fallback strategies to reuse content when fully localized assets are unavailable.[43][44]",
"PWA Kit multi‑site configuration using sites.js and default.js with domain and locale aliases.[34]"
],
"integration_patterns": [
"ERP or pricing services feeding different price books per site and currency.[43][42][45]",
"PIM driving localized attributes and media per locale while sharing global identifiers.[43][42]",
"Analytics and tagging configured per site with consolidated cross‑site reporting.[10][11]",
"Single OMS handling orders across multiple B2C Commerce sites with unified customer profiles.[21][22]"
],
"performance_considerations": [
"Reuse shared cartridges and libraries to benefit from common caches and avoid redundant deployments.[10][8][9]",
"Design URL and alias schemes that allow effective CDN caching across locales and domains.[10][34]",
"Keep locale catalogs lean and avoid over‑localized variants that complicate cache keys.[10][11][42]",
"Limit cross‑site dependencies that require synchronous calls between sites at runtime.[10]"
],
"security_considerations": [
"Apply consistent security settings (HTTPS, headers, roles) across all sites in an org.[18][14][15]",
"Ensure access control and permissions reflect business and regulatory differences per region.[18][14]",
"Use separate API clients or scopes per site when necessary to isolate integrations.[25][33]",
"Avoid leaking data between sites when they share databases or OMS integrations.[17][21]"
],
"common_pitfalls": [
"Inconsistent locale and currency configuration between sites, leading to broken experiences.[43][42]",
"Duplicating catalogs and content per site instead of using shared structures with overrides.[42][45]",
"Letting shared Page Designer libraries diverge, causing meta/data mismatches.[9]",
"Complex PWA routing rules that do not align cleanly with Business Manager site mappings.[34]"
],
"real_world_examples": [
"Brand managing separate EU, UK, and US sites with shared SFRA and Page Designer components but different locales and currencies.[8][42][45]",
"PWA Kit storefront serving multiple B2C sites from one codebase mapped via aliases and domains.[34]",
"Global retailer using locale fallback to gracefully handle partially localized content.[43][44]"
],
"interview_questions": [
{
"question": "How would you design catalogs, cartridges, and libraries for a multi‑brand, multi‑region implementation?",
"difficulty": "senior"
},
{
"question": "What are the trade‑offs between separate sites per country versus shared sites with locale‑based behavior?",
"difficulty": "senior"
},
{
"question": "How does PWA Kit handle multiple sites and locales, and how does that map back to Business Manager?",
"difficulty": "mid"
},
{
"question": "What strategies can you use to avoid data leakage between sites in a multi‑site org?",
"difficulty": "senior"
}
]
},
{
"name": "Checkout Architecture",
"core_concepts": [
"Checkout orchestrates basket, shipping, tax, payment, and order creation across storefront and back‑end services.[6][7][30]",
"SFRA provides reference checkout controllers and hooks that can be extended or overridden.[2]",
"Payment Service Providers integrate via cartridges and payment hooks invoked during checkout and customer service flows.[30][5]",
"Checkout flows differ between SFRA storefronts, OCAPI Shop clients, and SCAPI Shopper experiences, but share core concepts.[6][7][25]",
"Order data is passed to OMS or ERP systems after checkout for fulfillment and post‑purchase management.[46][21][22]",
"Security and compliance (PCI, fraud checks) are central design constraints for checkout.[17][18][14]"
],
"senior_explanation": "Checkout in SFCC is a coordinated process that turns an enriched basket into an order by invoking shipping, taxation, payment authorization, and fraud or OMS integrations through a mix of platform capabilities and cartridges.[6][7][30] SFRA defines reference controllers and payment hooks, while OCAPI and SCAPI expose equivalent operations for headless clients, all of which must be kept consistent from a business‑rules standpoint.[6][7][25][2] Payment providers are integrated through LINK or custom cartridges that implement provider‑specific logic behind common hook contracts, and order data is exported to OMS or ERP for fulfillment and returns.[46][21][30][22] Architects must balance UX, performance, security, and compliance by minimizing round trips, securing sensitive operations, and avoiding tight coupling to any single PSP or OMS.[10][17][18][14]",
"architecture_patterns": [
"SFRA checkout controllers backed by payment and tax hooks, with minimal custom logic in controllers.[2][30]",
"Headless checkout where a PWA or SPA uses SCAPI Shopper APIs and delegates payment to PSP SDKs.[7][31][34]",
"Service‑oriented checkout where a BFF service orchestrates SCAPI/OCAPI calls and external risk or tax services.[6][7][12]",
"Post‑checkout orchestration via OMS that handles capture, refunds, and fulfillment flows.[46][21][22]"
],
"integration_patterns": [
"PSP cartridges integrating via hooks for authorization, capture, and refunds across storefront and CS flows.[30][24][47][5]",
"Tax and duty services plugged in via cartridges or middleware during shipping and order review steps.[5][48]",
"OMS integration receiving orders from B2C Commerce and coordinating inventory and fulfillment.[46][21][22]",
"Fraud‑check integrations in pre‑ or post‑authorization steps using jobs or synchronous calls.[21][49]"
],
"performance_considerations": [
"Minimize synchronous external calls on the critical path; favor pre‑calculation or asynchronous post‑order processes.[10][12][21]",
"Optimize SCAPI or OCAPI usage with lean payloads and minimal expansions to keep latency low.[25][11][12]",
"Leverage CDN and caching for static assets while excluding personalized checkout steps from aggressive caching.[10][11]",
"Design idempotent checkout operations to avoid duplicate orders or charges on retries.[12][33]"
],
"security_considerations": [
"Enforce HTTPS and strong authentication/authorization on all checkout endpoints and operations.[18][14][15][33]",
"Ensure that sensitive objects such as orders and payment instruments require secure access methods and tokens.[16][14]",
"Avoid storing raw payment data in custom objects; rely on PSP tokens and platform cryptography.[16][30]",
"Implement CSRF protection and secure headers on checkout pages and APIs.[18][16][14]"
],
"common_pitfalls": [
"Embedding PSP‑specific logic directly into checkout controllers instead of using hooks and cartridges.[2][30][5]",
"Blocking checkout on slow external calls rather than using asynchronous order processing where possible.[10][12][21]",
"Inconsistent logic between SFRA, OCAPI, and SCAPI checkout paths leading to edge‑case discrepancies.[6][7][25]",
"Weak access controls around order modification endpoints in custom features.[16][14]"
],
"real_world_examples": [
"Stripe or PayPal LINK cartridges integrated into SFRA checkout with customer service support for payment changes.[30][24][5]",
"Retailer using Salesforce Payments and Salesforce Order Management to capture and refund via connected Stripe or PayPal accounts.[46][21]",
"Composable checkout built on a PWA Kit frontend with SCAPI Shopper APIs and PSP web components.[7][31][34]"
],
"interview_questions": [
{
"question": "How would you design a checkout flow that can switch PSPs with minimal impact on storefront code?",
"difficulty": "senior"
},
{
"question": "What are the key differences between implementing checkout with SFRA versus a SCAPI‑based headless storefront?",
"difficulty": "mid"
},
{
"question": "How do you ensure that order and payment operations are both idempotent and secure?",
"difficulty": "senior"
},
{
"question": "Where would you integrate OMS and fraud checks into the checkout lifecycle, and why?",
"difficulty": "senior"
}
]
},
{
"name": "Payment Gateway Integrations",
"core_concepts": [
"Payment providers typically integrate via LINK or custom cartridges implementing PSP‑specific logic.[2][24][5]",
"Cartridges register payment hooks that perform authorization, capture, refund, and tokenization operations.[30][24]",
"Business Manager configures payment processors, payment methods, and PSP service credentials.[30][24]",
"Salesforce Payments can be linked with Salesforce Order Management and external PSP accounts such as Stripe or PayPal.[46]",
"PSP cartridges must support both storefront checkout and Customer Service Center payment flows.[30]",
"Deprecated built‑in order management APIs are not used in newer payment integrations.[49]"
],
"senior_explanation": "Payment integrations on SFCC rely on PSP cartridges that encapsulate gateway‑specific behavior behind a common platform abstraction using jobs, hooks, and Business Manager configuration.[2][30][24][5] Implementations range from LINK cartridges for major providers to bespoke integrations using SFRA and OCAPI or SCAPI flows, all of which must adhere to security and compliance requirements while supporting refunds, partial captures, and multi‑instrument orders.[30][24][49] Salesforce Payments and Order Management provide additional native options where B2C Commerce merchant accounts are linked to core platform merchant and gateway records, offloading parts of the post‑purchase lifecycle.[46] A senior developer must design integrations to be loosely coupled, testable, and resilient to gateway outages, while enabling future gateway changes with minimal code impact.[46][30][5]",
"architecture_patterns": [
"LINK cartridge‑based PSP integration with configuration‑driven selection of payment methods and processors.[2][24][5]",
"Abstraction layer in a shared integration cartridge with provider‑specific implementations behind common hooks.[30][5]",
"Use of Salesforce Payments linked to OMS for unified capture and refund handling.[46][21]",
"Headless PSP integrations where frontends use PSP JS SDKs and SCAPI handles order creation.[7][31][24]"
],
"integration_patterns": [
"Cartridge‑level integrations where checkout and CS flows call payment hooks for authorization and capture.[30][24]",
"OMS‑aware integrations that delay capture until fulfillment, coordinated via OMS events.[46][21]",
"Multi‑PSP strategies with routing rules based on region, currency, or risk scoring.[46][47][5]",
"Using PSP webhooks or jobs to reconcile settlements and update SFCC orders.[21][49]"
],
"performance_considerations": [
"Minimize synchronous round trips to PSPs; consider auth‑then‑capture patterns tied to OMS.[10][46][21]",
"Implement reasonable network timeouts and retry policies while avoiding duplicate capture.[12][33][21]",
"Cache non‑sensitive PSP metadata (for example, available methods per country) where allowed.[35][12]",
"Ensure PSP client‑side components load efficiently and do not degrade checkout performance.[10][24]"
],
"security_considerations": [
"Avoid handling raw card data in custom code; rely on PSP‑hosted fields or tokenization.[16][30][24]",
"Protect secrets and credentials using platform‑approved secret storage patterns.[16]",
"Enforce strong authentication and authorization on any operations that change payment instruments.[16][14]",
"Comply with PCI and OWASP guidance, including secure headers and CSRF protections.[17][18][16]"
],
"common_pitfalls": [
"Hard‑coding PSP logic into storefront controllers rather than encapsulating in cartridges and hooks.[2][30][5]",
"Mixing deprecated order management APIs into new payment flows.[49]",
"Inadequate error and edge‑case handling for partial captures, reversals, or PSP downtime.[21][49]",
"Not aligning PSP configuration between B2C Commerce and external accounts, causing reconciliation issues.[46][24]"
],
"real_world_examples": [
"Stripe LINK cartridge configuring multiple payment processors and payment elements in Business Manager.[24]",
"Salesforce Payments and Order Management handling captures and refunds for Stripe and PayPal accounts linked to B2C Commerce.[46]",
"J.P. Morgan Payments cartridge connecting B2C Commerce storefronts directly to its payments platform.[47]"
],
"interview_questions": [
{
"question": "How would you design a PSP integration to allow switching providers with minimal downtime?",
"difficulty": "senior"
},
{
"question": "What are the key security responsibilities of a PSP cartridge versus the underlying platform?",
"difficulty": "mid"
},
{
"question": "How do you prevent duplicate charges when network retries occur during capture?",
"difficulty": "senior"
},
{
"question": "When should payment capture be deferred to OMS, and how would you implement that?",
"difficulty": "senior"
}
]
},
{
"name": "OMS/ERP/PIM Integrations",
"core_concepts": [
"OMS handles post‑purchase order orchestration, including fulfillment, returns, and refunds.[46][21][50]",
"Salesforce Order Management integrates natively with B2C Commerce and can consume orders from storefronts.[21][22]",
"ERP integrations typically synchronize pricing, taxation, financial data, and sometimes inventory.[21][50][48]",
"PIM integrations manage product master data, attributes, and media, pushing catalogs into SFCC.[6][25][45]",
"Integrations rely on APIs (OCAPI, SCAPI), jobs, and middleware to transform and route data.[6][7][20][21]",
"Real‑time versus batch decisions drive architecture, especially for inventory and pricing.[10][21]"
],
"senior_explanation": "OMS, ERP, and PIM integrations form the backbone of an enterprise‑grade SFCC implementation by externalizing master data management and post‑purchase orchestration.[6][25][45][21] Salesforce Order Management and third‑party OMS solutions receive orders from B2C Commerce, perform capture and fulfillment, and synchronize status and payments back to storefront and service channels.[46][21][22] PIM and ERP systems drive catalog, pricing, and sometimes inventory data into B2C Commerce via OCAPI, SCAPI Admin, and jobs, often mediated by middleware that enforces mapping, validation, and monitoring.[6][7][20][21] Senior engineers must define clear system‑of‑record boundaries, design for idempotency, and balance batch versus real‑time flows to ensure consistency and acceptable customer experience.[21][50][48]",
"architecture_patterns": [
"Hub‑and‑spoke integration with middleware acting as central orchestrator between SFCC and OMS/ERP/PIM.[21][50][48]",
"Direct integration between B2C Commerce and Salesforce Order Management using documented connectors.[46][21][22]",
"PIM‑driven product lifecycle where SFCC is a consumer of published catalog data only.[6][25][45]",
"Separated concern architecture with OMS owning order state, SFCC owning storefront views, and ERP owning financial records.[21][50]"
],
"integration_patterns": [
"Order export from SFCC to OMS via APIs or file drops triggered by jobs and webhooks.[20][21][22]",
"Price and tax imports from ERP into SFCC price books and tax tables.[6][25][21]",
"Catalog and media sync from PIM into B2C Commerce with locale‑specific attributes.[6][25][45]",
"Bi‑directional customer data sync between B2C Commerce and CRM or CDP systems.[21][50][48]"
],
"performance_considerations": [
"Align batch windows and job schedules with traffic patterns to reduce contention with storefront traffic.[10][28][20]",
"Use bulk operations and batch APIs where possible to reduce integration overhead.[25][20][51]",
"Design for eventual consistency in non‑critical data while keeping key flows (for example, order state) timely.[10][21]",
"Monitor integration latency and error rates to avoid hidden bottlenecks impacting UX.[21][48]"
],
"security_considerations": [
"Secure external connections with TLS, strong authentication, and scoped API credentials.[17][18][33]",
"Apply least‑privilege principles when granting OCAPI, SCAPI, or middleware access to SFCC resources.[25][18][33]",
"Sanitize and validate all incoming data from OMS/ERP/PIM to avoid corrupting storefront data.[17][18]",
"Ensure privacy and regulatory requirements are met when syncing customer and order data across systems.[17][18][16]"
],
"common_pitfalls": [
"Unclear system‑of‑record definitions causing conflicting updates between SFCC, OMS, and ERP.[21][50]",
"Tight coupling of storefront logic to specific OMS or ERP APIs.[21][50]",
"Over‑reliance on synchronous OMS calls during checkout, harming performance and resilience.[10][21]",
"Missing idempotency in order and catalog sync leading to duplicates or inconsistent states.[21][49]"
],
"real_world_examples": [
"Salesforce OMS integrated with B2C Commerce to manage multi‑channel fulfillment and service workflows.[21][22]",
"Global retailer using a PIM to manage catalogs and pushing localized assortments into SFCC sites.[6][25][45]",
"Enterprise leveraging middleware to orchestrate orders between SFCC, ERP, and warehouse systems.[21][50]"
],
"interview_questions": [
{
"question": "How would you define system‑of‑record boundaries across SFCC, OMS, ERP, and PIM in a large implementation?",
"difficulty": "senior"
},
{
"question": "Describe an architecture for exporting orders from B2C Commerce to Salesforce Order Management.",
"difficulty": "mid"
},
{
"question": "What strategies ensure idempotent and reliable order integrations between SFCC and OMS?",
"difficulty": "senior"
},
{
"question": "How would you handle near real‑time price changes coming from ERP into SFCC?",
"difficulty": "senior"
}
]
},
{
"name": "Inventory & Pricing Integrations",
"core_concepts": [
"Inventory and pricing can be mastered in SFCC, ERP, OMS, or specialized services depending on architecture.[10][45][21]",
"OCAPI and SCAPI support product price and availability endpoints that can be customized and configured.[7][25][26]",
"OCAPI settings allow controlling how availability and stock level information is exposed (for example, thresholds).[[26]]",
"Caching strategies and personalization heavily influence how inventory and prices are surfaced to shoppers.[10][11][12]",
"PIM and ERP integrations often drive base prices, with SFCC managing promotions and localized price books.[6][25][45]",
"OMS may act as inventory master for multi‑channel or omni‑channel scenarios.[21][50]"
],
"senior_explanation": "Inventory and pricing integration strategies in SFCC depend on which system owns real‑time data and how often it changes, balancing performance with accuracy.[10][45][21] SFCC can host price books and simple inventory, but many enterprises rely on ERP or OMS to supply prices, taxes, and stock information via OCAPI, SCAPI Admin, or jobs, often supplemented by inventory thresholds that hide exact stock levels for security.[6][7][25][26][21] Caching and CDN strategies must account for price and inventory personalization, including promotions, customer segments, and channels, influencing which data can be cached and for how long.[10][11][12] Architects must design idempotent, monitored flows for feeds and on‑demand lookups to avoid overselling, mispricing, or inconsistent shopper experiences.[10][21][48]",
"architecture_patterns": [
"ERP‑driven pricing with SFCC managing promotional layers and localized price books.[6][25][45][21]",
"OMS‑centric inventory with SFCC receiving periodic snapshots and using thresholds in APIs.[26][21]",
"Real‑time availability checks from OMS or inventory services for high‑value or low‑stock items.[10][21]",
"Hybrid approach combining cached base prices with real‑time price or inventory checks when necessary.[10][11][12]"
],
"integration_patterns": [
"Nightly or intra‑day feeds of price books and inventory from ERP/OMS into SFCC via jobs and OCAPI Data.[6][25][20][21]",
"SCAPI Admin‑based services feeding inventory changes or promotions more frequently.[7][27][12]",
"On‑demand lookups to OMS/ERP for specific steps such as cart validation or checkout.[10][21]",
"Channel‑specific price or inventory rules based on CRM or CDP segmentation.[21][48]"
],
"performance_considerations": [
"Use thresholds and approximate inventory for storefront reads to avoid real‑time stock queries on every request.[26][10][21]",
"Bulk update prices and inventory using jobs and batch APIs to minimize overhead.[25][20][51]",
"Cache price and inventory data at the application or BFF level when safe, aligning with TTLs and personalization.[10][35][12]",
"Avoid synchronous cross‑system calls in search and listing pages where scale is highest.[10][11][21]"
],
"security_considerations": [
"Avoid exposing exact inventory levels unless required; use max thresholds in OCAPI.[26][18]",
"Secure APIs between SFCC and ERP/OMS with authentication, encryption, and ACLs.[17][18][33]",
"Ensure pricing data is validated to prevent injection of incorrect or malicious values.[17][18]",
"Protect business‑sensitive pricing and availability from being scraped or abused via rate limiting.[18][33]"
],
"common_pitfalls": [
"Relying on real‑time external inventory checks in high‑traffic flows, hurting performance.[10][21]",
"Inconsistent price or tax logic split between SFCC and ERP, leading to shopper confusion.[21][48]",
"Not using inventory thresholds, inadvertently revealing precise stock positions.[26]",
"Weak monitoring of inventory and price feeds, causing silent data drift.[21][48]"
],
"real_world_examples": [
"ERP‑driven price updates loaded via OCAPI Data into SFCC price books multiple times per day.[6][25][21]",
"OMS‑managed inventory with SFCC only displaying availability bands, not exact quantities.[26][21]",
"Retailer using hybrid cached pricing with real‑time checks for VIP segments or complex offers.[10][11][48]"
],
"interview_questions": [
{
"question": "How would you architect inventory and pricing for a flash‑sale‑heavy site with high traffic?",
"difficulty": "senior"
},
{
"question": "When would you use OCAPI settings thresholds for inventory, and what trade‑offs do they introduce?",
"difficulty": "mid"
},
{
"question": "Describe a strategy to reconcile discrepancies between ERP prices and SFCC price books.",
"difficulty": "senior"
},
{
"question": "What are the performance implications of real‑time price and inventory checks during checkout?",
"difficulty": "mid"
}
]
},
{
"name": "Jobs & Schedulers",
"core_concepts": [
"Jobs automate multi‑step processes such as imports, exports, indexing, and data maintenance in B2C Commerce.[28][20][52]",
"Each job consists of one or more flows containing steps that can be system‑provided or custom.[28][20]",
"Jobs can run on demand or on schedules with recurrence rules and active windows.[28][20][52]",
"Resources can be locked to prevent concurrent modification of shared objects during job execution.[28][20]",
"Chunk‑oriented job steps process data in segments for scalability.[51]",
"Sandbox instances have limitations around scheduled jobs compared to production.[28][20]"
],
"senior_explanation": "The jobs framework in SFCC underpins operational reliability by orchestrating recurring and ad‑hoc tasks such as feed processing, cleanup, and integration flows.[28][20][52] Jobs are composed of flows and steps, mixing out‑of‑the‑box capabilities with custom steps that can run sequentially or in parallel, often with resource locking to avoid contention.[28][20] Chunk‑oriented job steps enable scalable processing of large datasets by reading, processing, and writing in controlled batches.[51] Senior engineers design job topologies, schedules, and resource locks around traffic patterns and SLAs to ensure integration stability and predictable storefront performance.[10][20][52][51]",
"architecture_patterns": [
"Integration jobs for imports and exports with clear separation between staging, validation, and commit steps.[20][52][51]",
"Nightly maintenance jobs for cleanup, indexing, and cache warming.[10][11][52]",
"Parallel flows within a job for independent tasks, with resource locks preventing conflicts.[28][20]",
"Chunk‑oriented jobs for large catalog or order datasets to avoid long‑running transactions.[20][51]"
],
"integration_patterns": [
"File‑based or API‑driven feeds processed by jobs that call OCAPI or external services.[6][25][20][52]",
"OMS/ERP integrations triggered or finalized by scheduled jobs.[20][21][22]",
"Monitoring and alerting jobs that report integration statuses to external systems.[52][48]",
"Jobs that manage sandbox refreshes or data seeding for CI/CD processes.[20][23]"
],
"performance_considerations": [
"Schedule heavy jobs during low‑traffic windows and avoid overlapping jobs that lock the same resources.[10][28][20]",
"Tune chunk sizes to balance throughput and memory usage in chunk‑oriented steps.[20][51]",
"Limit unnecessary logging and external calls within jobs to keep execution times predictable.[20][51]",
"Cap number of concurrent jobs to prevent contention; typical limits are documented.[28][20]"
],
"security_considerations": [
"Ensure jobs that handle sensitive data comply with encryption and secret‑handling best practices.[17][18][16]",
"Restrict who can create or edit jobs and job steps in Business Manager.[18][14]",
"Validate and sanitize all external data processed by jobs before committing to the platform.[17][18]",
"Rotate credentials used by integration steps and avoid hard‑coding them in scripts.[16]"
],
"common_pitfalls": [
"Scheduling too many jobs simultaneously, leading to resource contention and lock conflicts.[28][20]",
"Designing monolithic jobs that perform unrelated tasks instead of composable, focused jobs.[20][52][51]",
"Insufficient monitoring and alerting for job failures, causing unnoticed data issues.[52][48]",
"Using sandbox job behavior as a proxy for production without accounting for differences.[28][20][23]"
],
"real_world_examples": [
"Nightly product and price imports from PIM and ERP processed via chunk‑oriented jobs.[6][25][20][51]",
"Order export jobs sending B2C Commerce orders to Salesforce OMS and external ERPs.[20][21][22]",
"CI/CD processes provisioning on‑demand sandboxes with seeded data through automated jobs.[20][23]"
],
"interview_questions": [
{
"question": "How would you design a robust job flow to import large product catalogs with validation and rollback?",
"difficulty": "senior"
},
{
"question": "What factors influence your scheduling decisions for integration and maintenance jobs?",
"difficulty": "mid"
},
{
"question": "Explain the difference between task‑oriented and chunk‑oriented job steps and when to use each.",
"difficulty": "mid"
},
{
"question": "How do you avoid lock contention and race conditions between multiple jobs?",
"difficulty": "senior"
}
]
},
{
"name": "Performance Optimization",
"core_concepts": [
"Performance depends on coordinated caching across browser, CDN, web server, application server, and storage layers.[10]",
"Commerce SDK and SCAPI provide client‑side caching features like in‑memory and Redis caches.[35][12]",
"Effective caching moves content as close to the shopper as possible while respecting personalization.[10][12]",
"Platform guidance defines target response times and cache‑hit ratios for key storefront pages.[11]",
"Custom caches and hook implementations must be used selectively within SFCC limits.[12][13]",
"Integrations and jobs must be tuned to avoid impacting interactive storefront performance.[10][20][12]"
],
"senior_explanation": "Optimizing SFCC performance requires a holistic view of caching, code efficiency, and integration design across all layers from CDN to storage.[10][11][12] Salesforce publishes recommended response times and cache‑hit ratios for common storefront journeys, guiding architects to prioritize caching of home, search, and PDP pages while keeping dynamic operations like carts and checkout lean and uncached.[10][11] SCAPI and Commerce SDK introduce additional caching controls and custom cache features that must be sized and governed within documented limits to avoid eviction storms or stale data.[35][12][13] Senior engineers also minimize synchronous external dependencies, optimize promotions and hooks, and design jobs and integrations so heavy processing occurs off the shopper’s critical path.[10][20][12]",
"architecture_patterns": [
"Multi‑layer caching strategy covering CDN, page, fragment, and application‑level caches.[10][11][13]",
"BFF layer with its own cache for SCAPI responses, tuned per endpoint and personalization rules.[35][12]",
"Promotion and pricing strategies that avoid overly complex hook logic and excessive lookups.[12][48]",
"Segregated traffic patterns with separate APIs or hosts for headless and web flows where appropriate.[31][12]"
],
"integration_patterns": [
"Cache‑aware BFF that avoids redundant SCAPI or OCAPI calls and batches external requests.[35][12]",
"Asynchronous or batch integrations for heavy operations, avoiding synchronous calls in storefront flows.[10][20][21]",
"Use of custom caches for expensive, read‑heavy computations within storefront logic.[12][13]",
"Monitoring integrations and APIs with metrics and alerts tied to performance SLOs.[12][48]"
],
"performance_considerations": [
"Maximize CDN and page cache usage for anonymous traffic while handling personalization through lighter mechanisms.[10][11][12]",
"Tune custom cache sizes and eviction policies and stay within documented SFCC cache limits.[12][13]",
"Reduce payload size and chattiness in SCAPI/OCAPI calls via property selection and careful use of expand.[25][12]",
"Collaborate with merchandising to simplify complex promotion configurations that hurt hook performance.[12][48]"
],
"security_considerations": [
"Ensure caches do not leak personalized or sensitive data across shoppers by misusing cache keys.[10][12][18]",
"Configure HTTPS and secure headers without disabling needed performance features like HTTP/2.[18][16][15]",
"Respect privacy requirements when caching responses that contain user data.[17][18][33]",
"Avoid caching authenticated responses at shared layers such as CDN unless explicitly designed.[10][12][33]"
],
"common_pitfalls": [
"Treating caching as a template‑only concern instead of multi‑layer design.[10]",
"Overusing custom caches without clear invalidation strategies.[12][13]",
"Relying on upstream generic caches that ignore personalization, causing incorrect content.[10][12]",
"Not measuring performance against Salesforce benchmarks, leading to hidden degradation.[11][12]"
],
"real_world_examples": [
"Retailer improving PDP response times by tuning caching and reducing SCAPI expansions.[11][12]",
"Headless storefront using Commerce SDK Redis cache to reduce latency for frequently accessed APIs.[35][12]",
"Team reworking complex promotions after discovering they dominated hook execution time.[12][48]"
],
"interview_questions": [
{
"question": "How would you design a caching strategy for SFRA and a SCAPI‑based head to meet strict SLAs?",
"difficulty": "senior"
},
{
"question": "What are the main cache layers in SFCC and how do they interact?",
"difficulty": "mid"
},
{
"question": "How can promotion and hook design negatively affect performance and how would you mitigate this?",
"difficulty": "senior"
},
{
"question": "What techniques would you use to diagnose and resolve a sudden drop in cache‑hit ratio?",
"difficulty": "senior"
}
]
},
{
"name": "Caching Layers in SFCC",
"core_concepts": [
"Key layers include shopper browser, CDN, web server, application server, and storage/database.[10]",
"Effective strategy pushes caching up the stack (toward browser/CDN) to minimize backend work.[10]",
"B2C Commerce supports page, fragment, and custom caches at the application level.[10][12][13]",
"Commerce SDK adds in‑memory and Redis caching for SCAPI clients.[35]",
"Caching must account for personalization, localization, and session state.[10][12]",
"Cache headers and TTLs govern behavior across layers, including Cache‑Control.[10][35]"
],
"senior_explanation": "SFCC performance relies on coordinated caching across multiple layers, where each tier has distinct capabilities and responsibilities.[10][11] Browser and CDN caches are ideal for anonymous and semi‑static content, while application‑level page and fragment caches handle dynamic but cacheable server‑generated content.[10][11][13] Custom caches and Commerce SDK caches provide fine‑grained control for expensive computations or SCAPI calls, but must be designed with careful sizing, TTLs, and invalidation strategies.[35][12][13] Senior developers must understand how personalization, locale, and device segmentation affect cache keys and plan policies that avoid both over‑caching and under‑utilization.[10][35][12]",
"architecture_patterns": [
"CDN‑first design for static assets, category pages, and homepages with high TTLs.[10][11]",
"Fragment caching for reusable components such as nav, footers, or recommendations where possible.[10][11]",
"Custom caches for expensive lookups (for example, configuration, rules) used across controllers.[12][13]",
"Commerce SDK cache usage in BFFs to reduce SCAPI call volume.[35][12]"
],
"integration_patterns": [
"SCAPI and OCAPI responses cached at BFF or gateway layers when safe.[10][35][12]",
"External service responses (search, recommendations) cached application‑side with fallbacks.[10][12][13]",
"Jobs pre‑warming caches for key pages before peak traffic.[10][11][52]",
"Use of CDN features such as edge logic or surrogate keys for invalidation.[10]"
],
"performance_considerations": [
"Align cache keys with personalization dimensions to avoid collisions or under‑utilization.[10][12]",
"Keep cache entries within SFCC size limits to prevent evictions and warnings.[12][13]",
"Avoid stacking generic reverse proxies that are not aware of personalization.[10][12]",
"Monitor cache‑hit ratios and origin load to continuously tune policies.[10][11][12]"
],
"security_considerations": [
"Prevent caching of sensitive or user‑specific data in shared caches; control via headers and cache scopes.[10][12][18]",
"Enforce HTTPS and HSTS while configuring CDN to respect security headers.[18][16][15]",
"Avoid exposing session identifiers in cache keys or URLs.[16][14]",
"Ensure edge logic does not bypass authentication or authorization checks.[18][14][33]"
],
"common_pitfalls": [
"Assuming template‑level caching alone is sufficient for performance.[10]",
"Caching personalized responses at shared layers, causing data leakage between users.[10][12][18]",
"Ignoring locale and currency in cache keys, leading to incorrect content.[10][42]",
"Under‑using Commerce SDK caches in headless architectures, leading to unnecessary SCAPI load.[35][12]"
],
"real_world_examples": [
"Commerce site achieving recommended response times by combining CDN and application caching per Salesforce guidance.[10][11]",
"Headless storefront reducing SCAPI latency using Redis cache in Commerce SDK.[35][12]",
"Team refactoring custom caches to stay within SFCC limits and improve hit ratios.[12][13]"
],
"interview_questions": [
{
"question": "Outline a multi‑layer caching strategy for a highly personalized SFCC storefront.",
"difficulty": "senior"
},
{
"question": "How do you prevent sensitive data leakage through browser or CDN caches?",
"difficulty": "mid"
},
{
"question": "When would you introduce a custom cache, and how would you manage invalidation?",
"difficulty": "senior"
},
{
"question": "How can Commerce SDK caching improve SCAPI performance in a BFF architecture?",
"difficulty": "mid"
}
]
},
{
"name": "Security Best Practices",
"core_concepts": [
"Salesforce applies a secure development lifecycle aligned with OWASP and defense‑in‑depth principles.[17][18]",
"Core best practices include 2FA, least privilege, defense in depth, positive security models, and secure failure.[18]",
"Developers must protect against XSS, CSRF, injection, and other OWASP‑class vulnerabilities.[17][18][16]",
"Secure headers and HTTPS enforcement are key declarative defenses.[16][15]",
"Authentication and authorization best practices require server‑side checks for sensitive objects.[16][14]",
"Headless architectures require customers to secure their own presentation layers and BFFs.[33]"
],
"senior_explanation": "B2C Commerce security is a shared responsibility: Salesforce secures the platform and APIs, while customers must develop secure storefronts, integrations, and custom heads.[17][18][16][33] Recommended practices include enforcing 2FA on privileged accounts, using least privilege for users and API clients, deploying HTTPS with secure cookies, and adopting a positive security model to whitelist allowed inputs.[18][16][15] Developers must guard against XSS, CSRF, script injection, and insecure direct object references, relying on encoding, CSRF tokens, secure APIs, and robust access control checks for sensitive objects such as orders and payment instruments.[17][18][16][14] In headless builds, SCAPI endpoints remain secured by Salesforce, but PWA, BFF, and hosting stacks must implement standard web application security and rate limiting.[16][33]",
"architecture_patterns": [
"Centralized security cartridge enforcing HTTPS, headers, and shared middleware across sites.[18][16][15]",
"API clients with scoped permissions for OCAPI/SCAPI, separated per integration domain.[25][18][33]",
"BFF pattern enforcing server‑side authorization before calling SCAPI.[16][14][33]",
"Security logging and monitoring integrated with enterprise SIEM tools.[17][18]"
],
"integration_patterns": [
"Securely integrating identity providers via Account Manager SSO.[19]",
"Using encrypted channels and secrets management when connecting to PSPs, OMS, and ERPs.[17][18][16]",
"Implementing rate limiting and DoS protections at API gateways in front of SCAPI/OCAPI.[33]",
"Regular security assessments and penetration tests coordinated with Salesforce programs.[17]"
],
"performance_considerations": [
"Tune security controls (for example, headers, CSRF checks) to minimize overhead without weakening protection.[18][16]",
"Balance rate limits with throughput needs for SCAPI/OCAPI clients.[12][33]",
"Apply caching carefully so security decisions are not bypassed by cached responses.[10][12][18]",
"Use modern TLS configurations that support performance features such as HTTP/2.[18][15]"
],
"security_considerations": [
"Enforce HTTPS globally and configure secure cookies and modern TLS.[18][16][15]",
"Apply CSRF protections and use secure variants of APIs that require tokens or additional parameters.[16][14]",
"Encode all user‑control data outputs to prevent XSS and validate inputs server‑side.[17][18][16]",
"Store secrets securely and avoid embedding them in code or client‑side artifacts.[16]"
],
"common_pitfalls": [
"Relying on client‑side checks instead of server‑side authorization for sensitive operations.[16][14]",
"Leaving OCAPI or SCAPI clients over‑privileged and widely accessible.[25][18][33]",
"Incorrectly caching authenticated responses at shared layers.[10][12][18]",
"Not updating security configurations and headers as platform guidance evolves.[18][16]"
],
"real_world_examples": [
"Implementations enabling Enforce HTTPS and secure headers to support modern browser cookie security.[15]",
"Storefronts migrating to secure API usages that require tokens for sensitive operations.[16][14]",
"Headless deployments securing PWA Kit applications and BFF services while Salesforce secures SCAPI.[16][33]"
],
"interview_questions": [
{
"question": "How would you enforce least privilege across Business Manager users and API clients in a large SFCC org?",
"difficulty": "senior"
},
{
"question": "What measures would you implement to prevent XSS and CSRF in SFRA and headless storefronts?",
"difficulty": "mid"
},
{
"question": "Explain how Enforce HTTPS and secure headers contribute to SFCC security.",
"difficulty": "junior"
},
{
"question": "How do security responsibilities differ between standard SFRA and a SCAPI‑based headless architecture?",
"difficulty": "senior"
}
]
},
{
"name": "Debugging & Logging",
"core_concepts": [
"Effective logging is essential for diagnosing issues across cartridges, jobs, and integrations.[20][12][51]",
"Logs must be structured, leveled, and correlated to requests or jobs for traceability.[12][13]",
"Business Manager and external log aggregators are used to view and analyze logs.[20][48]",
"Debugging spans storefront (SFRA, Page Designer), OCAPI/SCAPI clients, and external systems.[6][7][8][12]",
"Monitoring and alerting should be in place for key metrics and error conditions.[12][48]",
"Sandbox and on‑demand environments support iterative debugging and profiling for CI/CD.[23]"
],
"senior_explanation": "Senior SFCC developers rely on disciplined logging and debugging practices to maintain complex, multi‑cartridge systems and integrations.[20][12][51] Logs should use consistent levels and structures that allow correlation of storefront requests, job runs, and external API calls, ideally aggregated into central observability platforms.[12][13][48] Debugging involves reproducing issues in appropriate environments, capturing relevant context without logging sensitive data, and working across boundaries such as SCAPI, OCAPI, OMS, and PSPs.[6][7][12][21] CI/CD pipelines with on‑demand sandboxes and automated tests help catch regressions early, while runtime monitoring detects performance or error anomalies in production.[12][23][48]",
"architecture_patterns": [
"Centralized logging strategy across cartridges and integration services feeding into an enterprise log platform.[12][13][48]",
"Correlation IDs flowing from frontends through BFFs to SFCC and downstream systems.[12][21]",
"Separate logging configurations per environment with production focusing on errors and key warnings.[20][23]",
"Structured logs designed for analysis (JSON or key‑value) rather than free‑form strings.[12][13]"
],
"integration_patterns": [
"Logging external API call latency and error codes to detect integration health issues.[12][21]",
"Job and scheduler logs feeding into monitoring for integration feeds.[20][52][48]",
"Utilizing Commerce SDK and SCAPI client logging options in headless architectures.[35][12]",
"Alerting on SCAPI or OCAPI rate limit responses or spike in 5xx errors.[12][33]"
],
"performance_considerations": [
"Avoid excessive logging in hot paths; use appropriate log levels and sampling.[12][13]",
"Ensure logging I/O does not dominate job or request execution time.[20][51]",
"Aggregate metrics from logs to detect performance regressions and cache issues.[10][11][12]",
"Use lower log verbosity in production and more detail in non‑prod environments.[20][23]"
],
"security_considerations": [
"Do not log sensitive data such as full payment details, tokens, or passwords.[17][18][16]",
"Protect logs in transit and at rest to prevent leakage of system internals.[17][18]",
"Limit access to logs to authorized staff and systems only.[18][14]",
"Redact or hash identifiers where logs must be shared across teams.[17][18]"
],
"common_pitfalls": [
"Unstructured, noisy logs that are difficult to query or correlate.[12][13]",
"Lack of monitoring around jobs and integrations, leading to late detection of failures.[20][52][48]",
"Debugging only in production rather than using sandboxes and CI environments.[20][23]",
"Logging sensitive data that violates security and compliance guidelines.[17][18][16]"
],
"real_world_examples": [
"Retailer adding correlation IDs and structured logs around SCAPI calls, reducing MTTR for incidents.[12][48]",
"Integration team wiring job logs into enterprise monitoring to track feed failures.[20][52][48]",
"CI/CD pipeline using on‑demand sandboxes and automated logs to validate builds.[23][53]"
],
"interview_questions": [
{
"question": "How would you design a logging strategy across SFRA, SCAPI, and external integrations?",
"difficulty": "senior"
},
{
"question": "What information must never appear in logs, and how do you enforce that?",
"difficulty": "mid"
},
{
"question": "How can you use logging and metrics to detect performance regressions on key pages?",
"difficulty": "senior"
},
{
"question": "How do on‑demand sandboxes and CI help with debugging complex SFCC issues?",
"difficulty": "mid"
}
]
},
{
"name": "Headless Commerce & PWA with SCAPI",
"core_concepts": [
"Headless architectures separate the storefront frontend from the commerce backend using APIs like SCAPI.[7][31][33]",
"PWA Kit and Composable Storefront provide reference React‑based heads for B2C Commerce.[31][34]",
"SCAPI Shopper APIs power catalog, cart, and checkout operations in headless builds.[7][32][31]",
"SCAPI Admin APIs and other services support back‑office operations via secure clients.[7][32]",
"Security, availability, and rate limiting responsibilities are split between Salesforce and the custom head owner.[33]",
"Multi‑site and multi‑locale support is handled via PWA Kit configuration mapping to Business Manager sites.[34]"
],
"senior_explanation": "Headless commerce on SFCC uses SCAPI as the contract between the platform and custom storefronts, enabling teams to build PWAs, mobile apps, and other experiences on modern stacks.[7][31][33] PWA Kit offers a reference implementation that integrates SCAPI Shopper APIs for browsing and purchasing while mapping multiple sites and locales through configuration.[31][34] In this model, Salesforce secures the APIs and commerce core while customers own security, performance, and reliability for their heads and any BFFs, which must implement robust auth, caching, and error handling.[16][33] Senior engineers must define API usage patterns, governance, and observability so that headless experiences remain consistent with SFCC’s capabilities and operational constraints.[31][12][33]",
"architecture_patterns": [
"PWA Kit head calling SCAPI via Commerce SDK, deployed on Managed Runtime.[31][35][34]",
"Custom BFF exposing a simplified domain API to multiple clients while consuming SCAPI and other services.[31][12][33]",
"Hybrid SPA/SFRA patterns where SFRA coexists with headless frontends during migration.[7][29][2]",
"Composable micro‑frontends where different teams own slices of the UI backed by shared SCAPI contracts.[31][34]"
],
"integration_patterns": [
"PWA using Commerce SDK caches and hooks to integrate with analytics, CMS, and personalization.[31][35][12]",
"Headless checkout with PSP web components and SCAPI order submission.[7][31][24]",
"Headless integrations with CRM, OMS, and CDP through BFF services in addition to SCAPI.[31][33][21]",
"Multi‑channel reuse of SCAPI contracts across web, mobile, and in‑store apps.[7][31]"
],
"performance_considerations": [
"Use Commerce SDK caching and CDN optimizations to keep SCAPI latency low.[10][35][12]",
"Design BFF endpoints to minimize chatty SCAPI usage and aggregate data efficiently.[35][12]",
"Apply PWA best practices (lazy loading, code splitting) for fast initial loads.[31][34]",
"Monitor SCAPI rate limits and response times across all consuming channels.[12][33]"
],
"security_considerations": [
"Implement secure auth flows in PWA/BFF layers, leveraging SLAS and secure token handling.[7][32][33]",
"Apply OWASP best practices to custom heads, including secure headers, CSRF protection, and XSS prevention.[18][16][33]",
"Treat SCAPI rate limits and DoS protections as part of defense in depth.[18][33]",
"Ensure proper separation of public and admin SCAPI clients and endpoints.[7][32][33]"
],
"common_pitfalls": [
"Calling SCAPI directly from browsers without BFF mediation where server‑side logic is needed.[12][33]",
"Ignoring headless security responsibilities under the assumption Salesforce covers them.[16][33]",
"Over‑fetching with SCAPI expand parameters, undermining performance.[12]",
"Reimplementing platform features (for example, promotions) in the head instead of using SCAPI/commerce logic.[7][31]"
],
"real_world_examples": [
"Retailers launching headless sites on PWA Kit backed by SCAPI to accelerate experimentation.[31][34]",
"Organizations running multi‑site PWA deployments from a single codebase mapped to multiple SFCC sites.[34]",
"Mobile and in‑store apps sharing SCAPI‑based services for unified shopper experiences.[7][31]"
],
"interview_questions": [
{
"question": "How would you architect a secure, multi‑site PWA on top of SCAPI and PWA Kit?",
"difficulty": "senior"
},
{
"question": "What are the pros and cons of using a BFF between PWA and SCAPI?",
"difficulty": "mid"
},
{
"question": "How do SCAPI security responsibilities differ between Salesforce and the customer in headless scenarios?",
"difficulty": "mid"
},
{
"question": "How would you migrate a legacy SFRA site to a headless PWA using SCAPI without a big‑bang cut‑over?",
"difficulty": "senior"
}
]
},
{
"name": "CI/CD & Release Management",
"core_concepts": [
"B2C Commerce provides multiple instance types (sandbox, development, staging, production) for release workflows.[23]",
"CI/CD aims to keep main branches always releasable with automated validation.[54][23]",
"On‑demand sandboxes support ephemeral environments for integration and testing.[23]",
"Version control (for example, Git) is the source of truth for cartridges and configuration artifacts.[54][53]",
"Best practices include frequent small commits, automated tests, and clear branching strategies.[54][55][53]",
"Environment management and data synchronization are key for reliable deployment pipelines.[54][23][53]"
],
"senior_explanation": "CI/CD for SFCC combines Salesforce’s multi‑instance architecture with modern DevOps practices around version control, automation, and environment management.[54][23][53] Teams use source control as the single source of truth for cartridges, OCAPI settings, and Page Designer metadata, with CI pipelines running tests and validations on sandboxes or development instances before promoting to staging and production.[54][23][53] On‑demand sandboxes and xlarge profiles support production‑like testing, while practices like small, frequent commits, clear branching, and automated validations reduce deployment risk.[54][23][55][53] Release management also requires coordination of data migrations, job schedules, and integration endpoints across environments to ensure consistency.[20][23][53]",
"architecture_patterns": [
"Three‑stage pipeline: build/test on sandbox, integration on development, UAT on staging, then production deploy.[23]",
"Git‑based branching models (for example, trunk‑based or Gitflow) adapted to SFCC teams.[54][53]",
"Automated job and configuration deployment via scripts or tools to keep environments in sync.[20][23]",
"Use of on‑demand sandboxes for short‑lived integration environments in CI.[23][53]"
],
"integration_patterns": [
"CI pipelines that run automated tests hitting SFRA, SCAPI, and OCAPI endpoints.[54][23]",
"Deployment scripts updating OCAPI settings and cartridge paths in line with code releases.[25][26][23]",
"Coordinated releases with OMS, ERP, and PSP teams to align API versions and endpoints.[21][24][22]",
"Static analysis and security scans integrated into CI stages.[17][54][53]"
],
"performance_considerations": [
"Keep CI test data sets representative but not excessive to avoid long build times.[23]",
"Use appropriate sandbox sizes (for example, xlarge) for performance testing where needed.[23]",
"Parallelize tests where feasible without exceeding environment limits.[54][23]",
"Monitor deployment impacts on cache warm‑up and job schedules.[10][20][11]"
],
"security_considerations": [
"Control CI/CD credentials tightly and use secure storage for secrets.[17][18][53]",
"Limit who can approve production deployments and enforce segregation of duties.[18][54]",
"Scan code and dependencies for vulnerabilities as part of the pipeline.[17][54][53]",
"Ensure test data in sandboxes does not expose real customer PII unnecessarily.[17][18]"
],
"common_pitfalls": [
"Manual, ad‑hoc deployments that bypass version control or validation.[54][55]",
"Drifting configuration between environments due to manual changes.[25][26][23]",
"Large, infrequent releases that are hard to test and roll back.[54][55]",
"Overloaded sandboxes with full production data slowing CI cycles.[23]"
],
"real_world_examples": [
"Teams using on‑demand sandboxes spun up and torn down per CI run.[23][53]",
"Retailers adopting trunk‑based development with continuous validation to production.[54][55]",
"Enterprises scripting OCAPI settings and job configuration deployment as part of releases.[25][26][20][23]"
],
"interview_questions": [
{
"question": "How would you design a CI/CD pipeline for SFCC that supports multiple teams and frequent releases?",
"difficulty": "senior"
},
{
"question": "What configuration artifacts beyond code must be managed in version control for reliable deployments?",
"difficulty": "mid"
},
{
"question": "How do on‑demand sandboxes change your approach to integration and performance testing?",
"difficulty": "mid"
},
{
"question": "What strategies would you use to keep B2C Commerce and OMS/ERP releases aligned?",
"difficulty": "senior"
}
]
},
{
"name": "Common SFCC Anti-patterns",
"core_concepts": [
"Directly modifying base or vendor cartridges instead of using overlays.[1][2][5]",
"Embedding complex business logic in templates or controllers without modularization.[3][2][13]",
"Over‑customizing OCAPI or SCAPI instead of leveraging platform capabilities.[25][27][12]",
"Treating SFCC as a generic app server, ignoring its commerce‑oriented patterns and limits.[10][12][13]",
"Building tightly coupled integrations without clear system‑of‑record boundaries.[21][50]",
"Neglecting caching, performance, and security guidance from Salesforce documentation.[10][11][18]"
],
"senior_explanation": "Anti‑patterns in SFCC often stem from ignoring the platform’s reference architectures and operational constraints, leading to brittle implementations and upgrade pain.[1][3][2] Editing core or LINK cartridges, copy‑pasting templates, or packing controllers with monolithic logic undermines SFRA’s modularity and makes future Salesforce updates risky.[1][3][2][5] Similarly, treating OCAPI/SCAPI as generic databases, bypassing caching and performance guidance, and building tightly coupled point‑to‑point integrations can create long‑term scalability and reliability issues.[25][10][11][12][21] Senior developers must recognize and correct these patterns early by reinforcing best practices across code, architecture, and operations.[10][11][18][48]",
"architecture_patterns": [
"Refactoring legacy SiteGenesis‑style duplication into SFRA overlays and hooks.[3][2]",
"Separating core commerce logic, integration logic, and presentation into dedicated cartridges and services.[2][21]",
"Replacing point‑to‑point integrations with hub‑oriented or BFF‑mediated architectures.[21][50][48]",
"Aligning API usage with Salesforce recommendations (SCAPI for new work, OCAPI selectively).[[7][25][27]]"
],
"integration_patterns": [
"Avoiding synchronous, tightly coupled integrations in critical storefront paths.[10][12][21]",
"Using standardized message schemas and mapping layers instead of exposing raw platform objects externally.[21][50]",
"Implementing idempotent integration endpoints and replay‑safe job patterns.[20][51][21]",
"Centralizing integration monitoring and error handling.[12][48]"
],
"performance_considerations": [
"Refactor heavy hooks, promotions, and controllers that cause slow responses.[11][12][48]",
"Eliminate unnecessary external calls in high‑traffic controllers and APIs.[10][12]",
"Correct misuse of custom caches that exceed limits or lack clear invalidation.[12][13]",
"Adopt Salesforce performance benchmarks and continuously measure against them.[11][12]"
],
"security_considerations": [
"Replace insecure API usages and direct object access with secure, tokenized methods.[16][14]",
"Remove logs and debug code that leak sensitive information.[17][18][16]",
"Enforce HTTPS and security headers where they were previously omitted.[18][15]",
"Harden over‑permissive OCAPI and SCAPI clients.[25][18][33]"
],
"common_pitfalls": [
"Copying legacy SiteGenesis patterns into SFRA rather than embracing its design.[3][2]",
"Bypassing hooks and cartridges by hard‑coding integration logic in controllers.[2][30][5]",
"Underestimating the impact of promotions, jobs, and data volumes on performance.[10][20][12]",
"Ignoring security and compliance guidance, leading to audit and incident risks.[17][18][16]"
],
"real_world_examples": [
"Project that modified app_storefront_base and could not easily adopt new SFRA releases.[1][2]",
"Implementation suffering from slow pages due to complex promotions and hooks before refactoring.[11][12][48]",
"Integration landscape rebuilt from brittle point‑to‑point connections to a more resilient hub model.[21][50][48]"
],
"interview_questions": [
{
"question": "What SFCC anti‑patterns have you seen in real projects, and how did you address them?",
"difficulty": "senior"
},
{
"question": "Why is modifying base or vendor cartridges problematic, and what is the correct alternative?",
"difficulty": "mid"
},
{
"question": "How can misuse of promotions and hooks degrade performance on SFCC?",
"difficulty": "mid"
},
{
"question": "Describe an integration anti‑pattern and how you would redesign it for resilience.",
"difficulty": "senior"
}
]
},
{
"name": "Senior-Level eCommerce System Design",
"core_concepts": [
"Enterprise eCommerce design spans storefront, APIs, integrations, data, security, and observability.[10][12][21][48]",
"System‑of‑record boundaries between SFCC, OMS, ERP, CRM, and PIM are foundational decisions.[45][21][50]",
"Headless and composable approaches use SCAPI as a core contract for multiple channels.[7][31][33]",
"Non‑functional requirements (availability, performance, security, compliance) drive many architectural trade‑offs.[10][11][18][33]",
"CI/CD, testing, and environment strategies enable safe, frequent change.[54][23][53]",
"Data and personalization strategies tie commerce to analytics and marketing platforms.[21][48]"
],
"senior_explanation": "Senior‑level eCommerce design on SFCC requires balancing business capabilities with platform strengths, defining clear ownership across systems, and building for change.[10][11][45][21][48] Architects determine where to use SFRA, Page Designer, or headless SCAPI heads, and how to integrate OMS, ERP, PIM, CRM, and CDP so that each system owns well‑defined domains.[7][31][45][21][50][48] Non‑functional goals such as global performance, availability, and security inform choices about caching, multi‑region deployments, and incident response, while CI/CD and environment design enable safe frequent releases.[10][11][18][54][23] At this level, patterns, guardrails, and standards matter as much as individual implementations, because multiple teams and vendors collaborate over years on the same estate.[17][18][54][48]",
"architecture_patterns": [
"SFCC‑centric architecture with SFRA/Page Designer for web and SCAPI for additional channels.[2][31][8]",
"Headless composable architecture with SCAPI, PWA Kit, and microservices/BFFs.[31][34][33]",
"Hub‑and‑spoke integration using middleware between SFCC and OMS/ERP/PIM/CRM/CDP.[21][50][48]",
"Multi‑site, multi‑locale design with shared assets and localized overrides.[8][42][45]"
],
"integration_patterns": [
"Event‑driven or near real‑time integrations for orders and inventory, batch for catalogs and analytics.[10][20][21]",
"Standardized APIs and schemas for external systems instead of ad‑hoc per‑consumer interfaces.[21][50][48]",
"Unified customer view across CRM and SFCC via bi‑directional data sync.[21][48]",
"Analytics and personalization loops using commerce, OMS, and marketing data.[21][48]"
],
"performance_considerations": [
"Global CDN strategy, locality‑aware hosting for heads, and tuned caching as first‑class design elements.[10][11][34]",
"Scaling SCAPI usage via BFF caching, rate limit‑aware designs, and API governance.[35][12][33]",
"Designing catalog, promotions, and jobs to support high‑traffic events.[10][20][12]",
"Capacity planning and load testing using production‑like sandboxes.[10][11][23]"
],
"security_considerations": [
"Holistic security model across SFCC, custom heads, and integrated systems using zero‑trust and defense‑in‑depth.[17][18][16][33]",
"Alignment with compliance requirements (for example, PCI) for payments and data handling.[17][18][30]",
"Standardized auth patterns (SSO, OAuth2) across internal and external apps.[14][19]",
"Centralized security monitoring and incident response covering all components.[17][18][33]"
],
"common_pitfalls": [
"Under‑specifying non‑functional requirements and discovering limitations late in the program.[10][11][18]",
"Treating commerce, OMS, and marketing as separate silos instead of an integrated system.[21][50][48]",
"Failing to design for adaptability, leading to expensive rework as products and channels evolve.[7][31][48]",
"Inadequate governance around API usage, integrations, and customization patterns.[25][12][54]"
],
"real_world_examples": [
"Global multi‑brand rollout using SFCC, Salesforce OMS, and CRM with headless storefronts in multiple regions.[45][34][21]",
"Enterprise replatforming to a composable architecture with SCAPI, PWA Kit, and microservices.[31][34][33]",
"Retailer centralizing data and personalization across SFCC and marketing platforms to drive higher conversion.[21][48]"
],
"interview_questions": [
{
"question": "Design a multi‑region, multi‑brand eCommerce architecture on SFCC, including OMS, ERP, and headless storefronts.",
"difficulty": "senior"
},
{
"question": "How do you approach non‑functional requirements such as availability and performance in SFCC system design?",
"difficulty": "senior"
},
{
"question": "What principles guide your decisions about where to place business logic across SFCC, OMS, and middleware?",
"difficulty": "senior"
},
{
"question": "How would you evolve an existing monolithic SFCC implementation toward a more composable architecture over time?",
"difficulty": "senior"
}
]
}
]
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment