Which solution will provide the MOST reliability for ticket sale transactions during periods of high load?
Create a separate service in the ECS cluster for the waiting room. Use a separate scaling configuration. Ensure that the ticketing service uses the JWT information and appropriately forwards requests to the waiting room service.
Move the application to an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. Split the waiting room module into a pod that is separate from the ticketing pod. Make the ticketing pod part of a StatefulSet. Ensure that the ticketing pod uses the JWT information and appropriately forwards requests to the waiting room pod.
Create a separate service in the ECS cluster for the waiting room. Use a separate scaling configuration. Create a CloudFront function that inspects the JWT information and appropriately forwards requests to the ticketing service or the waiting room service.
Move the application to an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. Split the waiting room module into a pod that is separate from the ticketing pod. Use AWS App Mesh by provisioning the App Mesh controller for Kubernetes. Enable mTLS authentication and service-to-service authentication for communication between the ticketing pod and the waiting room pod. Ensure that the ticketing pod uses the JWT information and appropriately forwards requests to the waiting room pod.
Explanations:
While creating a separate service in the ECS cluster for the waiting room and using a separate scaling configuration could help, it does not address the issue of load on the waiting room affecting ticket sale transactions. There is no mention of optimizing how requests are routed based on the JWT information, which could lead to increased latency and further impact availability.
Moving to Amazon EKS and separating the waiting room into a different pod does provide more flexibility and potential for scaling. However, using a StatefulSet for the ticketing pod may not be necessary or beneficial, as stateful applications are typically for workloads that require stable network identities or persistent storage. Additionally, this option does not offer a direct solution for load management based on JWTs, which is critical for maintaining reliability during high traffic.
Creating a separate service for the waiting room with a distinct scaling configuration allows for better management of load. Implementing a CloudFront function to inspect JWT information and route requests to either the ticketing service or the waiting room service optimizes traffic flow based on current capacity. This approach minimizes the impact of high loads on the ticket sale transactions while effectively managing the waiting room process.
Moving to EKS and utilizing AWS App Mesh introduces complex service-to-service communication but does not inherently resolve the core issue of load management during peak times. While mTLS authentication enhances security, it does not address the application’s reliability or the critical need to manage high user loads efficiently. Additionally, this option may overcomplicate the architecture without providing significant benefits over the other simpler options.
Based on what I know, the answer is:
Create a separate service in the ECS cluster for the waiting room. Use a separate scaling configuration. Create a CloudFront function that inspects the JWT information and appropriately forwards requests to the ticketing service or the waiting room service.