Week 10

NoSQL Databases scale vertically.

• True

• False

DynamoDB can be replicated across multiple AZs

• True

• False

You have setup your DynamoDB with Provisioned Capacity Mode 5 RCU & 5 WCU. During a busy day on your application, your users started complaining about getting an exception. When you looked at your application, you see that users are indeed getting an exception called ProvisionedThroughputExceededException. Which of the following are true in this scenario?

• Your application hit 5 RCU and 5 WCU limit and anything more that that cannot handle load.

• Your application maxed out on 5 RCU and 5 WCU then used Burst Capacity as well but still it was not enough for the busy read and write traffic and DynamoDB started throwing the exception.

• After 5 RCU & 5 WCU, dynamodb should’ve switched to Auto Scaling capacity. There is probably something else is going on in your application.

• You should’ve just used RDBMS instead of DynamoDB. You start thinking about a big refactoring.

• To avoid this situation, you should’ve implemented an exponential back-off strategy to limit number of users getting this exception and exhausting all your RCUs and WCUs including Burst Capacity.

You are building a new application and your client asked for a high performant architecture. You have decided that you’ll design the application around DynamoDB to take advantage of its performance. After your team has released the beta version, admins of the application on the client side started complaining about how they create a new item but then they cannot see the item in the list but once they refresh the page multiple times, they finally see the item they create. What could be the possible cause of this glitch?

• DynamoDB is slow and sometimes it’s ok to see inconsistencies when entering data.

• This is the standard behavior of DynamoDB. DynamoDB does eventually consistent reads.

• There is probably an exception when admins create new items. You should debug your application to understand the root cause.

• You probably forgot to include “ConsistentRead” parameter in your “List” query and in a Write/Read scenario, application may be reading from a different server that is still processing replication.

You are tasked with designing the Cost Model for a a specific application that expects reads and writes with no expectations of scaling. User Base is small and it’s for an internal dashboard that your client uses. Your maximum item size in this internal dashboard is 12 KB as it contains some text and some urls. It’s expected that there will be no more than 10 entries into the system and these items will be retrieved a maximum of 20 times per second. You decided you don’t need caching and you will use Provisioned Capacity Mode of DynamoDB. After some discussions, it has been decided that eventual read is sufficient for your client. What will be the RCUs and WCUs you will need to provision per second?

• 120 WCUs & 30 RCUs

• 1200 RCUs & 36 RCUs

• 12 WCUs & 24 RCUs

• 100 WCUs & 48 RCUs

You & your team built a multi-tenant application that uses DynamoDB as its data store that will serve multiple clients. You designed your DynamoDB table to partition based on client_id. After some time, there is a JIRA ticket opened that mentioned Client A users keep getting ProvisionedThroughputExceededException. You check logs and see that no other clients are experiencing this issue. Based on this information which of the following could be true?

• It is probably a data corruption issue and when application is serializing/deserializing DynamoDB items, application is probably crashing.

• You have not enforced size limit and Client A has large text blobs that exceeds 400 KB in size. Size of the items exhaust all RCUs and WCUs and Burst Capacity does not help in this situation.

• Client A is on a different region therefore there is some latency for them.

• Client A is using the system heavily and partitioning all information based on just client_id may not be enough. This may be causing a “Hot Partition” issue. 

You worked on a part of an application that uses DynamoDB as its datastore. QE did not approve your changes due to a bug in your code. They complained, whenever they update a field on an item, they see that the whole item is replaced and all other fields other than the field they updated are nullified. What could be the possible cause of this bug?

• You used a PATCH endpoint that partially updates the item. You see that instead of UpdateItem, you used PutItem in your repository class.

• You forgot to add ConsistentRead flag on your read. So when QE looks at the item right after they update, they don’t see the changes right away.

• You should always send the whole object to update fields but your endpoint is not built that way.

• This is the side effect of using DynamoDB as there is no partial updates in DynamoDB.

You are working on a discovery for a client where client needs backend APIs to provide functionality for their internal users’ day to day activities. Your client has a third party identity management provider to manage user identities and groups. You and your team has chosen API Gateway as your api technology. What is the best way to setup API Gateway to authenticate client users?

• Create a Cognito user pool for users to create new users and manage authorization through Cognito.

• Create IAM roles for each user and manage their permissions through IAM Policies.

• Create a lambda function to communicate with clients identity management provider.

• Create a DynamoDB table to store users and their permissions. Create a custom lambda authorizer to access dynamodb and authenticate users.

Your client has an existing API Gateway that works with Lambdas. You are working on a new version of these lambdas. You would like to deploy these lambdas but you don’t want to interrupt production. How would you build this so that you successfully test the new version of lambdas successfully.

• Write bunch of unit tests to make sure Lambda’s work as expected.

• Deploy your lambdas as is as API Gateway will handle this automatically.

• Test your lambdas locally and ship them. You never write bad code.

• Create a new API Gateway Stage and use stage variables to call your new lambdas to test.

You completed testing of new version lambdas in a new API Gateway Stage and results show that everything works as expected. Your client wants to roll this out slowly and only let some of the requests go to the new implementation and monitor the performance for a while before rolling them out to everyone. What is the best way to accomplish this?

• Create a new AWS Account and deploy the whole stack with a new API Gateway configured in the new account.

• Keep switching between lambda configurations manually on AWS Console until client is satisfied.

• Create a Canary Deployment strategy and start with only 10% of requests. This way you can monitor new lambdas performance and affirm that everything is working expected.

• Tell your client what they are asking is not feasible.