Key-Value NoSQL
A hash map at planet scale: put(key, value), get(key), and not much else — but extremely fast and horizontally scalable.
What it is
Key-value stores expose the simplest possible interface: a single key maps to an opaque value (bytes, JSON (JavaScript Object Notation), or a structured record depending on the system). There are no joins, no secondary indexes by default, and queries are restricted to key lookups and (sometimes) prefix scans. The simplicity is the point — it lets the system shard trivially by hashing the key, and reads/writes are O(1) on a single node. Examples range from Redis (in-memory) to DynamoDB (durable, distributed) to etcd (consistent, small).
Why senior interviewers ask
Senior interviewers ask 'why DynamoDB?' to see if you can name access patterns. The KV model forces you to model data around how it'll be queried — which is either liberating or a nightmare depending on whether requirements are stable.
Key points
- Primary access pattern: get/put by primary key; some support sort keys for range scans.
- Trivially shardable by hashing the primary key — no rebalancing surprises.
- Most systems offer secondary indexes (GSIs in DynamoDB) but they're eventually consistent.
- No joins — denormalize or do app-side joins.
- Transactions are limited (DynamoDB TransactWriteItems supports up to 100 items, same region).
- Latency at p99 is the killer feature: single-digit ms at any scale.
- Pricing is per-request, which can be either cheap or shockingly expensive depending on access patterns.
Pros
- Horizontal scale is essentially free — add nodes, hash takes care of distribution.
- Predictable single-digit-ms latency at any scale (DynamoDB's selling point).
- Operational simplicity: managed services (DynamoDB, ElastiCache) require near-zero tuning.
- Schema flexibility — values are opaque, evolve without migrations.
- Great fit for session stores, caches, feature flags, simple lookups.
Cons
- Forces you to know access patterns up front — adding a new query may require a new table or GSI.
- Cross-key transactions are limited or expensive.
- Analytics are impossible inside the store — you ship to a warehouse.
- Hot keys are catastrophic — one popular item can melt a partition.
- Modeling many-to-many or graph-shaped data is awkward.
When to choose
- Access patterns are small, fixed, and known in advance.
- Extreme write throughput or single-digit-ms p99 latency required.
- Session storage, caches, feature flags, rate-limit counters.
- Shopping carts, user preferences, leaderboards (Redis sorted sets).
- IoT device state where each device is a key.
When to avoid
- Ad-hoc reporting or analytics — there's no SQL (Structured Query Language).
- Many-to-many relationships with frequent joins.
- Requirements that will evolve unpredictably.
Real systems
Interview probe
'Walk me through your DynamoDB schema for this feature.' Answer: list the access patterns first (get user, list user's orders, list orders by status), then derive the partition key, sort key, and GSIs. Never start with the table.