A company is building a voting system for a popular TV show, viewers win watch the performances then visit
the show’s website to vote for their favorite performer. It is expected that in a short period of time after the
show has finished the site will receive millions of visitors. The visitors will first login to the site using their
Amazon.com credentials and then submit their vote. After the voting is completed the page will display the
vote totals. The company needs to build the site such that can handle the rapid influx of traffic while
maintaining good performance but also wants to keep costs to a minimum. Which of the design patterns
below should they use?
A.
Use CloudFront and an Elastic Load balancer in front of an auto-scaled set of web servers, the web servers
will first can the Login With Amazon service to authenticate the user then process the users vote and store the
result into a multi-AZ Relational Database Service instance.
B.
Use CloudFront and the static website hosting feature of S3 with the Javascript SDK to call the Login With
Amazon service to authenticate the user, use IAM Roles to gain permissions to a DynamoDB table to store the
users vote.
C.
Use CloudFront and an Elastic Load Balancer in front of an auto-scaled set of web servers, the web servers
will first call the Login with Amazon service to authenticate the user, the web servers will process the users
vote and store the result into a DynamoDB table using IAM Roles for EC2 instances to gain permissions to the
DynamoDB table.
D.
Use CloudFront and an Elastic Load Balancer in front of an auto-scaled set of web servers, the web servers
will first call the Login. With Amazon service to authenticate the user, the web servers win process the users
vote and store the result into an SQS queue using IAM Roles for EC2 Instances to gain permissions to the SQS
queue. A set of application servers will then retrieve the items from the queue and store the result into a
DynamoDB table.
D
I’m not sure but D looks good.
The answer is B.
You can host javascript SDK on S3 and write data to DynamoDB. S3 has very good performance for rapidly influx of traffic why keep the cost minimum
B does not solve the writing contention, obviously.
D
Hey,
diibin got narrowed the view , as the req states “maintaining good performance but also wants to keep costs to a minimum” well this means as much as possible , why not to use the s3 static website feature for this. which is also supports JS SDK as well. The flow is simple and effective ,
User(req)–> CDN(CF) S3(Js SDK) AMAZON (auth) DynamoDB and thats it !! All done in a piece here
This is referred by acloudguru video !! Happy sharing 🙂
Will B answer the rapid influx of millions of visitors? I do not know what size the current EC2 instance is – and B does not have an auto-scale. I am still leaning towards D.
You don’t need EC2 with option B.
D looks the best. SQS queue in front of the DB tier will act as a buffer to help mitigate a sudden, massive burst in writes bogging down on the DB tier. Front-end web servers can just handle the incoming votes, and fire-and-forget into the SQS queue as fast as they come in. At that point, it is just up to the back-end worker instances to pull the votes out of the queue and write them into the DB at their leisure. (Might give serious consideration to using a Lambda function to pull out of the queue and write into DynamoDB, rather than using a fleet of worker instances. Why add more instances for something that repeatable and event-driven?)
Why is B not an option?
I would also go with D. Because this provides scalability asked for without hitting the DynamoDB performance virtual limits.
B is not the right answer because it lacks the scalability, doesn’t address the write performance in a cost effective manner. The key point which eliminates B is that there is a dynamic content display requirement for the app (ie, after the vote, results should be displayed to voter). My vote is for D 🙂
I would go with B
D is the right answer.
Problem with B and C is that with millions of visitors it is possible to exceed your provisioned throughput rate of writes to DynamoDB. Also remember that there is soft limit of 10,000 writes/second.
See https://aws.amazon.com/dynamodb/faqs/#Scalability,_Availability_&_Durability
Q: Is there a limit to how much throughput I can get out of a single table?
If you wish to exceed throughput rates of 10,000 writes/second or 10,000 reads/second, you must first contact Amazon through this online form.
I’m leaning D, but B is still very tempting. Acloudguru mentioned he did 10 million hits for a movie release with s3 static sites – it’s very cheap, very scalable, and can definitely host javascript (client side). The dynamoDB limit is of course a soft limit (40k max read/write in US virginia and 20k elsewhere per table).
You could theoretically go over your SQS limits as well (http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/limits-queues.html):
120,000 inflight messages per queue. If you reach this limit, Amazon SQS returns the OverLimit error message. To avoid reaching the limit, you should delete messages from the queue after they’re processed. You can also increase the number of queues you use to process your messages.
For FIFO queues, there can be a maximum of 20,000 inflight messages per queue. If you reach this limit, Amazon SQS returns no error messages.
This looks to me more liek a developer associate question.
I would have gone with C
1> You have to collect millions of votes qualifying answers BCD
2> Keep cost minimum B
3> Display results after voting is completed CD I am not sure if B can even do this
D
site will receive millions of visitors (votes), so SQS is appliciable here.
D, – not C because of DynamoDB soft limit.
In deciding between B and D, I favor B because of how well it can scale during a huge spike. With D, you need to be concerned about how well the ELB will scale:
https://aws.amazon.com/articles/1636185810492479
And even if you did “Pre-Warm the Load Balancer”, can the auto scaling spin up the EC2 instances fast enough to handle the huge spike? And then if the spike causes autoscaling to spin up a crazy amount of EC2 instances, that would not “keep costs to a minimum” as the question requested.
I think working with Amazon to handle the DynamoDB writing contention is a better option. Option B is also costs much less.