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:
- All search request hits the AEM publishers.
- 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.
- The Sling Servlet being scalable is limited by the numbers of AEM publisher servers available.
- 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:
- All search requests hits a micro-service, and away from AEM.
- The search requests will not affect any processing from the AEM publishers.
- The search requests will not consume the CPU, memory, and I/O resources
- The micro-service will have caching abilities.
- The micro-service will be resuable across the organization.
- The micro-service will be scalable.
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.