Module 11 · Lesson 01
The technology map: categories before names
Interviewers remember the reason you chose a category, not the vendor you named.
What you will be able to do
- Place any tool into its storage or messaging category
- Name the trade-off each category is built around
- Avoid picking a tool before the access pattern is known
- Justify a choice with three properties, not with popularity
Storage categories
| Category | Optimised for | Pays for it with | Examples |
|---|---|---|---|
| Relational | Joins, transactions, constraints | Vertical limits, sharding complexity | PostgreSQL, MySQL |
| Key-value | Point lookups at high rate | No queries beyond the key | Redis, DynamoDB |
| Document | Nested objects, flexible schema | Weak cross-document joins | MongoDB, DocumentDB |
| Wide-column | Huge write volume, time-ordered scans | Rigid query patterns | Cassandra, Bigtable, HBase |
| Search | Full-text, faceting, relevance | Write amplification, eventual index | Elasticsearch, OpenSearch |
| Analytics columnar | Aggregates over billions of rows | Not for point reads | ClickHouse, BigQuery, Redshift |
| Object storage | Cheap durable blobs | High latency, no partial updates | S3, GCS |
| Coordination | Small strongly-consistent metadata | Tiny data limits, consensus latency | etcd, ZooKeeper |
Read the chart as a decision
If you need multi-row transactions, you are in the relational column. If you need a billion writes a day keyed by time, wide-column. If you need relevance ranking, a search index beside the source of truth — not instead of it.
The rest of the stack
- Cache: Redis or Memcached for shared state; in-process for the hottest small objects.
- Message queue: SQS, RabbitMQ, Celery-style workers — one consumer per message, retries and delay.
- Stream log: Kafka, Kinesis, Pulsar — replayable, partitioned, many independent readers.
- CDN: static and cacheable responses at the edge; the cheapest latency win available.
- Load balancer: L4 for TCP throughput, L7 for routing, retries, TLS and header logic.
- API gateway: auth, quotas, and a stable contract in front of many services.
- Workflow engine: durable multi-step processes with retries and timers.
- Observability: metrics, logs, traces — three products, often three vendors.
PostgreSQL single node
10-50k simple TPS
More with tuning and replicas
Redis single node
100-200k ops/s
Pipelined, small values
Cassandra node
10-50k writes/s
Scales linearly with nodes
S3 GET p99
50-200 ms
Never on a request hot path
How to choose in an interview
State the access pattern
"Point read by short code, 100:1 read to write, 500 bytes per value."
Name the constraint that decides
Transactions, scale of writes, query flexibility, or latency. One constraint usually settles it.
Pick a category, then a tool
"A key-value store — Redis with persistence, or DynamoDB if the dataset outgrows memory."
Say what you give up
Every choice has a cost. Naming it proves you are not reciting a list.
The habit that reads as senior
"I'd start with Postgres because the data is relational and the volume fits one primary with replicas. I'd add a cache for the read-heavy endpoint and move to a wide-column store only if write volume outgrows it."
Worth remembering
- Categories exist because of trade-offs; if there were no trade-off, there would be one database.
- Choose from the access pattern: read shape, write rate, consistency need, size of data.
- Managed services are a legitimate answer when the design is about the system, not the operations.
- One boring relational database plus a cache is the correct answer more often than any interview answer suggests.
Checkpoint
Answer all 3 questions to finish the lesson.
1. You need multi-row transactions and ad-hoc queries. Which category?
Transactions and flexible joins are what relational engines exist for; the others trade those away for scale or query shape.
2. A search index is usually paired with a source of truth because…
Search engines optimise retrieval, not durable authoritative state. Writes are indexed asynchronously and can fail independently.
3. What is the strongest justification for a storage choice?
Design decisions are justified by requirements — read shape, write rate, consistency, size — not by popularity.