AEMCS Target Architecture Overview | Community
Skip to main content
N
nsvsrk
Level 8
March 4, 2026
Solved

AEMCS Target Architecture Overview

  • March 4, 2026
  • 2 replies
  • 45 views

Hi all,

 

Target Architecture Overview at https://chatgpt.com/c/69a67b3a-0454-83ab-98e2-e88377ba2365 shows the below:


Auto-Scaled Publish Tier (AEMCS)
↓
Commerce Engine + Microservices
↓
Author Tier (Content Teams)

 

My question is why is Commerce Engine between Publish and Author?

 

Commerce integration is required only for Publish and not Author?

 

Appreciate all responses.

 

Thanks,

RK.

    Best answer by VishalKa5

    Hi ​@nsvsrk ,

     

    In AEM as a Cloud Service (AEMCS), the Commerce Engine is shown between Publish and Author mainly to represent the logical flow of content and commerce data, not because it physically sits between them. Commerce integration is heavily used on the Publish tier because that is where live users interact with product data, pricing, inventory, cart, and other real-time services. These runtime calls must happen on Publish for performance, scalability, and security reasons, especially since Publish auto-scales based on traffic. However, Commerce is not limited to Publish only. The Author tier also connects to Commerce, but mainly for product selection, catalog browsing, and previewing product information while creating content. Author does not handle live transactions or heavy commerce traffic.

    Key Points:

    • Commerce layer placement in the diagram is logical, not physical.

    • Publish uses Commerce for real-time product data and customer interactions.

    • Author uses Commerce mainly for product selection and preview.

    • Live commerce traffic should not go through Author.

    • Architecture ensures scalability, performance, and security separation.

    Thanks

    2 replies

    AmitVishwakarma
    Community Advisor
    AmitVishwakarmaCommunity Advisor
    Community Advisor
    March 4, 2026

    Hi ​@nsvsrk 
    Commerce is not literally “between” Publish and Author. In a correct AEM+Commerce architecture, both Author and Publish talk to the Commerce engine in parallel, usually via CIF (Commerce Integration Framework). The diagram you saw is just a simplified “stack” and should really show Commerce as a backend system behind the AEM tiers, not as a proxy between them.

    Commerce integration is needed on both tiers, but for different reasons:

    • Publish: mandatory for live traffic — pricing, inventory, cart, checkout, PDP/PLP data, etc.
    • Author: used for authoring and enrichment — product pickers, category pickers, product console, merch content, previews.

    So: no, Commerce is not “only for Publish”; Publish uses Commerce for runtime, and Author uses Commerce to author and configure those experiences.

    Replication is still Author -> Publish only; Commerce is not part of that path. It’s just drawn in the middle to show that both tiers depend on it, but network‑wise Author and Publish call Commerce independently.

    Amit Vishwakarma - Adobe Commerce Champion 2025 | 16x Adobe certified | 4x Adobe SME
      VishalKa5
      VishalKa5Accepted solution
      Level 6
      March 4, 2026

      Hi ​@nsvsrk ,

       

      In AEM as a Cloud Service (AEMCS), the Commerce Engine is shown between Publish and Author mainly to represent the logical flow of content and commerce data, not because it physically sits between them. Commerce integration is heavily used on the Publish tier because that is where live users interact with product data, pricing, inventory, cart, and other real-time services. These runtime calls must happen on Publish for performance, scalability, and security reasons, especially since Publish auto-scales based on traffic. However, Commerce is not limited to Publish only. The Author tier also connects to Commerce, but mainly for product selection, catalog browsing, and previewing product information while creating content. Author does not handle live transactions or heavy commerce traffic.

      Key Points:

      • Commerce layer placement in the diagram is logical, not physical.

      • Publish uses Commerce for real-time product data and customer interactions.

      • Author uses Commerce mainly for product selection and preview.

      • Live commerce traffic should not go through Author.

      • Architecture ensures scalability, performance, and security separation.

      Thanks

        N
        nsvsrkAuthor
        Level 8
        March 4, 2026

        Thanks ​@VishalKa5 .

        “ These runtime calls must happen on Publish for performance, scalability, and security reasons, especially since Publish auto-scales based on traffic.”.

         

        Kindly clarify on Publish auto-scaling.

        Author does not auto-scale?

         

        Thanks,

        RK.

        Terms & ConditionsAccessibility statement

        Loading footer...