Scenario: Building AEM Components with 3rd Party Integrations in a High Performance and Scalable Way

we are assigned to build a hospital search component in a very high traffic website. This hospital search component allows users to search for available hospital private rooms across the United States; there are approximately 200,000 hospital private rooms across the US.  The hospital search component, presented in the view, simply has an input field that allows a user to search for postal code, and a filter to filter by facilities and distance. When a search is made successful, the hospital search component will show a structured HTML grid view of 20 room availabilities to the users. When a search is made unsuccessful, a message of “no results” will be shown.

How can we build a high performance and scalable solution for this requirement? Below is “the non-optimized” and “the optimized” solutions for my recommended implementations.

1. Non-Optimized, Unacceptable Solution

For this solution, the Sling Servlet with the /bin/my-app/search endpoint will be utilised. This Sling Servlet will accept the HTTP POST request. When the HTTP POST request is made to /bin/my-app/search, the AEM server will process the request with logic where it will make a server-side HTTP Client request to the third-party API, waits for the response, and returns JSON as results. With the JSON results returned from the third-party API, the AEM server-side logic will format and return the appropriate JSON data to the AEM front-end component.

The example below is an inefficient implementation because:

  1. All search request hits the AEM publishers.
  2. All search request made to the AEM publisher are not cached; though including a caching mechanism may be more complicated when integrating this strategy into AEM.
  3. The Sling Servlet being scalable is limited by the numbers of AEM publisher servers available.
  4. All search concurrent requests made to the AEM publsher will consume the CPU, memory, and I/O resources, therfore other visitors may experience a delay.

2. Optimized, Better Solution

For this solution, the AEM front-end component makes the HTTP POST request directly from the client to the third-party API. The third-party API process the request and returns the correct formatted JSON data. Next, the AEM front-end component will render HTML elements to the page.
The example below is a more efficient implementation because:

  1. All search requests hits a micro-service, and away from AEM.
  2. The search requests will not affect any processing from the AEM publishers.
  3. The search requests will not consume the CPU, memory, and I/O resources
  4. The micro-service will have caching abilities.
  5. The micro-service will be resuable across the organization.
  6. The micro-service will be scalable.




Last Thoughts:
For most high traffic AEM sites, we typically try to offload as much processing from our AEM live-publish instances to reduce CPU resources being used, and to maintain good performance.


Hello, I am an enthusiastic Adobe Community Advisor and a seasoned Lead AEM Developer. I am currently serving as an AEM Technical Lead at MNPDigital.ca, bringing over a decade of extensive web engineering experience and more than eight years of practical AEM experience to the table. My goal is to give back to the AEM Full Stack Development community by sharing my wealth of knowledge with others. You can connect with me on LinkedIn.

Leave a Reply

Your email address will not be published. Required fields are marked *


Back To Top