Een bedrijf exploiteert een maaltijdbezorgdienst. Door recente groei ondervindt het orderverwerkingssysteem van het bedrijf schaalproblemen tijdens piekuren. De huidige architectuur omvat Amazon EC2-instances in een Auto Scaling-groep die bestellingen verzamelen van een applicatie. Een tweede groep EC2-instances in een Auto Scaling-groep voert de bestellingen uit. Het orderverzamelproces verloopt snel, maar het orderuitvoeringsproces kan langer duren. Gegevens mogen niet verloren gaan als gevolg van een scaling-gebeurtenis. Een solutions architect moet ervoor zorgen dat zowel het orderverzamelproces als het orderuitvoeringsproces adequaat kunnen schalen tijdens piekuren. Welke oplossing voldoet aan deze vereisten?

De correcte optie is het provisioneren van twee Amazon SQS-wachtrijen en het schalen van Auto Scaling-groepen op basis van het aantal berichten in elke wachtrij. Dit ontkoppelt het orderverzamel- en orderuitvoeringsproces, waardoor elk proces onafhankelijk kan schalen. SQS zorgt voor duurzaamheid van berichten, wat betekent dat gegevens niet verloren gaan tijdens schaalgebeurtenissen. De Auto Scaling-groepen kunnen dynamisch reageren op de werkelijke vraag, gemeten aan de hand van de wachtrijlengte, wat efficiënte resource-allocatie garandeert. De andere opties zijn minder effectief: Het configureren van minimale capaciteit op basis van piekbelasting is inefficiënt en duur, omdat er constant te veel resources worden gebruikt. Het creëren van extra Auto Scaling-groepen via SNS is te complex en niet de meest directe manier om schaalproblemen op te lossen. Schalen op basis van meldingen die de wachtrijen verzenden is niet specifiek genoeg; het aantal berichten in de wachtrij is een directere en effectievere metric voor dynamisch schalen.