A web tier stores user session data and always retrieves it by session ID; it never searches by any other attribute, and each lookup must complete in well under a millisecond. Which database type best fits this access pattern?
Select an answer to reveal the explanation.
Short Explanation
Think of a coat check: you hand over a ticket, you get your coat back, and nobody searches the racks. When every read is by one exact key and speed is everything, that's a key-value store. Don't overbuild it with joins or traversals you'll never use.
Full Explanation
A key-value store maps a unique key to a value and is optimized for exactly one operation: given the key, return the value. Because there is no query planner, no join and no secondary filtering on the hot path, lookups are typically served from memory with very low latency, which is why session caches are the textbook key-value use case. The session payload can be any serialized blob, since the application never filters inside it. A graph database is optimized for traversing relationships between nodes; storing sessions as nodes adds traversal machinery that a single-key lookup does not need. A column-oriented store groups values by column to accelerate analytical scans over many rows, which is the opposite of fetching one small record by its identifier. A relational design that joins sessions to user and device tables on every read adds parsing, planning and join work to a request that only needs one record, so it works against the latency requirement rather than serving it. Exam caveat: if the requirements changed to searching sessions by user, region or expiry time, a store that can index inside the value would become a better fit. Operational check: confirm that every access path in the application code uses the session ID alone, then load-test the lookup and compare latency against the stated target.