Firma hostuje trójwarstwową aplikację e-commerce w AWS. Strona internetowa jest hostowana na Amazon S3 i integruje się z API na trzech instancjach Amazon EC2, znajdujących się za Application Load Balancer (ALB). API obsługuje statyczne i dynamiczne treści front-endowe oraz workerów backendowych, którzy asynchronicznie przetwarzają żądania sprzedaży. Firma spodziewa się nagłych, dużych skoków w żądaniach sprzedaży podczas wprowadzania produktów na rynek. Co powinien zalecić architekt rozwiązań, aby zapewnić pomyślne przetworzenie wszystkich żądań?

Poprawna odpowiedź to dodanie dystrybucji Amazon CloudFront dla treści statycznych i kolejki Amazon SQS. CloudFront, jako sieć dostarczania treści (CDN), skutecznie buforuje treści statyczne, zmniejszając obciążenie instancji EC2 i poprawiając wydajność dla użytkowników. Amazon SQS jest kluczowy dla obsługi nagłych skoków ruchu, ponieważ działa jako bufor, który asynchronicznie przyjmuje żądania sprzedaży. Dzięki temu aplikacja może przetwarzać żądania w swoim tempie, bez przeciążania instancji EC2 i utraty danych, nawet gdy liczba żądań znacznie przekracza bieżące możliwości przetwarzania. Pozostałe opcje są mniej skuteczne: Dodanie CloudFront dla treści dynamicznych jest możliwe, ale buforowanie treści statycznych przynosi większe korzyści w kontekście zmniejszania obciążenia. Zwiększanie liczby instancji EC2 ad-hoc nie zapewnia elastyczności Auto Scaling. Umieszczenie instancji EC2 w grupie Auto Scaling jest dobrym rozwiązaniem, ale dodanie CloudFront tylko dla treści statycznych jest bardziej efektywne niż dla dynamicznych w celu zmniejszenia obciążenia. Dodanie ElastiCache przed ALB nie jest standardową ani efektywną architekturą dla buforowania żądań sprzedaży i może wprowadzić niepotrzebną złożoność.