Add a second access pattern to a key-value store
secondary indexing in NoSQL.
add a global secondary index on EmailAddress, weighing extra storage, write amplification, and eventual consistency.
a full scan with a filter, or assuming indexes are free.
What's really being asked
This is a NoSQL data-modeling problem. The interviewer wants to see that you know access patterns must be designed in advance and that querying on a non-key attribute requires a secondary structure, not a scan.
The full answer
A key-value store can only look up efficiently by its key, here UserID. Querying by EmailAddress with a Scan plus filter reads every item and discards non-matches, which is slow and bills you for all the data read. The right answer is a global secondary index whose partition key is EmailAddress. DynamoDB maintains the GSI automatically: every base-table write is propagated to the index, and lookups by email become a targeted Query that reads only matching items. You project only the attributes the new feature needs to keep the index small. Discuss costs honestly: the GSI roughly duplicates indexed and projected data so storage grows, each base write now also consumes write capacity on the index, and the GSI is eventually consistent, so a just-written user may not appear immediately.
The mistakes people make
Proposing a full Scan with a FilterExpression, which still reads the entire table. Assuming a GSI is free or strongly consistent. Projecting all attributes when only a few are needed, inflating cost. Ignoring write amplification on the base table.
What usually comes next
When would a local secondary index fit instead, and why must it share the partition key? How do you handle a GSI hot partition if many users share a domain? What if email must be unique? How does projection type affect read cost?
A concrete example
A users table is keyed on UserID. Login by email requires finding a user from their address. You create a GSI named email-index with partition key EmailAddress projecting only UserID and displayName. Login now issues a Query on email-index returning the single matching item in milliseconds. You accept the added storage, the extra write unit per user write, and the small eventual-consistency window after sign-up.
Interview question
To query a DynamoDB table by a non-key attribute without scanning, what is the correct approach and its main tradeoff?
- a.Create a global secondary index on the attribute; it adds storage and write capacity cost and is eventually consistentCorrect
- b.Run a Scan with a FilterExpression; it costs nothing extra because filters run server-side
- c.Change the table's primary key to the new attribute, which has no downsides
- d.Enable strong consistency on the base table so non-key queries become free
Why? this is the answer
A GSI turns the lookup into a targeted query but duplicates data, consumes write capacity per base write, and is eventually consistent. A filtered Scan still reads the whole table, so it is not a real solution.
Just read this? Test yourself on what you have been reading.
Read the original → docs.aws.amazon.com
- #dynamodb
- #global-secondary-index
- #nosql
- #data-modeling
- #indexing
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles