“I’ll use Kafka” is not an answer. “This needs a durable, replayable log to decouple producers from consumers, so I’ll use Kafka” is. Interviewers are listening for whether you can map a requirement to a technology and justify it — naming a brand without the reason is the junior tell this whole course is built to cure.
This lesson is a quick-reference decision guide. For each tool: what it is, and the one-line signal that should make you reach for it. The Common Components lesson covers the categories (load balancers, caches, queues, CDNs); this one is about naming specific tools and defending the choice.
Datastores
PostgreSQL — the strong default. A battle-tested relational database with ACID transactions, joins, constraints, and JSONB for semi-structured data. Reach for it when you need transactional correctness, relational queries, or simply a sensible default you can scale a long way with read replicas and partitioning. Starting from Postgres and justifying a move away from it is a more credible story than reaching for something exotic first.
Cassandra — write-heavy and multi-region. A wide-column store built on an LSM-tree with leaderless replication and tunable consistency (an AP system). Reach for it when writes dominate, the data is keyed by a known partition key, you never need cross-row joins, and you want linear horizontal scale across regions — event logs, messaging, time-series, feeds.
DynamoDB — managed key-value at predictable scale. A fully managed key-value / document store with single-digit-millisecond latency and automatic partitioning. Reach for it when you want Cassandra-like scale without operating it yourself and your access is key-based. The catch is the same as Cassandra’s: you model the table around the query and choose the partition key carefully.
Redis — the in-memory multi-tool. An in-memory data-structure store. Reach for it when you need a cache, a distributed lock, a rate limiter, a leaderboard (sorted sets), a session store, or lightweight pub/sub. It is the default answer to “how do we make this read fast” and to several contention problems. For how it actually works under load, see the dedicated Redis In-Depth course.
Messaging & streaming
Kafka — the durable log. A partitioned, replicated, append-only commit log with consumer groups and retention. Reach for it when you need to decouple producers from consumers, buffer write spikes, fan an event out to many consumers, or feed a stream processor — and when you want the ability to replay history. It is the backbone of most event-driven and analytics designs. The Apache Kafka course goes deep on partitioning, delivery semantics, and consumer groups.
Flink — stateful stream processing. A stream processor with keyed state, event-time windowing, watermarks, and exactly-once checkpointing. Reach for it when the question involves continuous aggregation over a firehose — real-time analytics, trending/top-K, fraud detection, click aggregation. Kafka moves the events; Flink computes over them.
Search & coordination
Elasticsearch — full-text and faceted search. A distributed search engine built on inverted indexes. Reach for it when you need full-text search, autocomplete, faceted filtering, or log search — things a LIKE '%...%' query in a relational database cannot do at scale. Treat it as a secondary index you feed from your source of truth, not as your primary store.
ZooKeeper / etcd — coordination. Strongly-consistent key-value stores built on a consensus protocol. Reach for it when a design needs leader election, distributed locks with fencing, service discovery, membership, or dynamic configuration — anywhere you need exactly one owner of something across a cluster. (See the Consensus and Coordination lesson.)
API Gateway — the edge. The single entry point in front of your services. Reach for it when you need to centralize authentication, routing, rate limiting, TLS termination, and request shaping at the edge so individual services don’t each reimplement them.
How to use this in the interview
A quick mapping you can say out loud:
| Requirement | Reach for |
|---|---|
| Make reads fast / lock / rate-limit | Redis |
| Durable event log, decoupling, replay | Kafka |
| Write-heavy, multi-region, key-based | Cassandra / DynamoDB |
| Transactions, joins, strong default | PostgreSQL |
| Full-text / faceted search | Elasticsearch |
| Continuous aggregation over a stream | Flink |
| Leader election, locks, config | ZooKeeper / etcd |
| Auth, routing, rate-limit at the edge | API Gateway |
Interview tip: Always pair the tool with the requirement in the same sentence — “write-heavy and keyed by device_id, so Cassandra,” not just “Cassandra.” And don’t over-reach: a managed Postgres handles far more than people expect, so justify why the simpler default won’t work before adding a specialized store.
Key Takeaways
- Name the technology and the requirement together. The requirement should select the tool, not the other way round.
- Default to PostgreSQL and justify moving away from it; reach for Cassandra/DynamoDB for write-scale and key-based access, Redis for caching and contention.
- Kafka moves events, Flink computes over them — the pair behind most streaming and analytics designs.
- Elasticsearch for search, ZooKeeper/etcd for coordination, an API Gateway at the edge — specialized tools for specialized jobs.
- Don’t over-engineer. Fewer, well-justified technologies beat a zoo of trendy ones; explain why the simple option is insufficient before adding complexity.