A company is creating a new web application for its subscribers. The application will consist of a static single page and a persistent database layer. The application will have millions of users for 4 hours in the morning, but the application will have only a few thousand users during the rest of the day. The company's data architects have requested the ability to rapidly evolve their schema.
Which solutions will meet these requirements and provide the MOST scalability? (Choose two.)
Deploying Amazon DynamoDB with on-demand capacity is ideal for handling traffic that can spike within seconds or minutes, which is crucial for the application's millions of users in the morning. It provides the most scalability without the need for precise traffic predictions. Utilizing Amazon S3 to host the static content and provisioning an Amazon CloudFront distribution maximizes performance and scalability for content delivery, efficiently handling large bursts of traffic to ensure availability and quick access to the static single page.
Changing answer to A,D. DynamoDB on-demand is more scalable than DynamoDB auto-scaling.
For those answering A over C, the question asks about scalability, but the text says the traffic patterns are known and don't state they will change. Both auto-scaling and on-demand can "scale", but auto-scaling is for known, on-demand is better for unknown traffic patterns. Its likely the "scalability" is more to do with the file hosting (EC2 wouldn't scale well at all vs S3)
"Most scalability" = A. Might be more expensive, but cost is irrelevant in the question.
Question asks for "most scalability", not cost optimization. "DynamoDB auto scaling ... modifies provisioned throughput settings only when the actual workload stays elevated or depressed for a sustained period of several minutes. ... This means that provisioned capacity is probably best for you if you have relatively predictable application traffic, run applications whose traffic is consistent, and ramps up or down gradually."
"The on-demand pricing model is ideal for bursty, new, or unpredictable workloads whose traffic can spike in seconds or minutes, and when under-provisioned capacity would impact the user experience." Whereas on-demand capacity mode is probably best when you have new tables with unknown workloads, unpredictable application traffic and also if you only want to pay exactly for what you use. The on-demand pricing model is ideal for bursty, new, or unpredictable workloads whose traffic can spike in seconds or minutes, and when under-provisioned capacity would impact the user experience. https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/capacity.html
AD vs CD ? 1) Please read the final sentence. Which solutions will meet these requirements and provide the "MOST" scalability? 2) It is not possible to predict an exact boundary based on the number of "millions of users". So I would choose "AD".
The exact boundary is known, the application's subscribers. Leaning towards AC now.
rapidly evolve their schema, MOST scalability for data layer = DynamoDB with on-demand capacity. on-demand capacity mode automatically enables autoscaling. MOST scalability for single page app = Amazon CloudFront distribution with the S3 bucket as the origin.
Provisioned mode is more suitable and it is the default.
For autoscaling we need to know the lower and upper limits. Anh the question says....application will have millions of users for 4 hours in the morning....how many millions , how much upper limit we need to set for to handle this much request? here we can't have exact estimation for the upper limit in autoscaling. Thus, better option is (A)
With autoscaling we can face throttling initially, when there is surge of requests and the load is greater than the scaling upper limit. We can gradually increase the upper limit of autoscaling and would be then able to handle the load in subsequent requests preventing ourself from using OnDemand. Thus Option (C) is more scalable as it can handle the both types of load(high & low) in efficient manner.
A: On-demand scaling because the demand changes drastically (millions to thousands) D: S3 for static page is perfect B: Aurora is RDMS so not much rapid schema changes (it's subjective and DBA will argue but better options on the table are DynamoDB) E: Too much work and overhead
To be fair, 4 hours is a strange time duration for burst traffic. 20 hours of low traffic may benefit from auto-scaling's as it is long enough to be called a "depressed" traffic mode in autoscaling config. 4 hours in the morning can also be termed as "sustained period" of burst in autoscaling. This question is not theoretical, someone who has scaled Dynamo in similar scenarios will be able to answer correctly.
Provisioned on-demand capacity: Manual: Requires manual setup and management of capacity. Cost-Effectiveness: Requires manual estimation of workload, which can result in either excess or insufficient capacity. Use Case: Suitable for relatively stable workloads with predictable capacity needs. predictable capacity needs.：4 hours in the morning,a few thousand users during the rest of the day.
B is valid, but not good as A
No, "ability to rapidly evolve their schema" -> Relational DB is out
It is a known traffic https://aws.amazon.com/dynamodb/pricing/
on-demand capacity for DynamoDB since traffic is not consistent, and S3 & CloudFront for static files
MOST scalability - DynamoDB On-Demand > Auto Scaling + Static Content host in S3
(A) is incorrect. "On-demand capacity mode is probably best when you have new tables with unknown workloads, unpredictable application traffic." We know the workload upper limit is the total amount of subscribers & we know it's busy in the morning & not so much in the afternoon. Nothing in the question says it bursts in the morning. (C) is correct. The traffic pattern is known, so prep for the morning & the exact upper boundary is the # of subscribers.
The traffic pattern is known here.
I understand the argument between A and C, but why not B?
"Ability to rapidly evolve their schema" -> NoSQL database, schema changes in transactional databases like RDS are difficult
CD as pattern is known