Courses › System Design › Key Technologies

Choosing a Technology

Which technology to reach for, by requirement — with sensible defaults and common stacks per question.

You don't need to know dozens of technologies — you need to pick the right one quickly and justify it in a sentence. This guide maps common interview needs to the technology pages in this section. Use it to choose, then read the linked page for the details you'll be asked about in the deep dive.

[!TIP] Default first, then justify a change Start every design with a small set of defaults: PostgreSQL for data, Redis for caching, S3 for files, Kafka or SQS for asynchronous work. Switch to something more specialized only when a requirement forces you to, and say which requirement it is. "We need X because of Y" earns more credit than an impressive list of tools.

Choosing a primary database

Caching and fast lookups

Search and specialized queries

Files and large objects

Asynchronous work and messaging

[!WARNING] Kafka is not always the answer If the requirement is "send a welcome email after signup," a task queue is simpler. Choose Kafka when several consumers need the same events, you need replay, or volume is very high.

Data processing and analytics

[Services] -> {Kafka} -> [Flink: real-time] -> (ClickHouse: dashboards)
{Kafka} -> (S3: raw events) -> [Spark: batch] -> (Warehouse: reporting)

Infrastructure and coordination

Common pairings by question type

[!INTERVIEW] How to say it "I'll use PostgreSQL as the source of truth because bookings need transactions. Search needs full-text and geo filters, so I'll sync listings to Elasticsearch through CDC on Kafka. Photos go to S3 behind a CDN. I'm not adding anything else until a requirement calls for it."