Engineering Atlas › System Design Interviews

Picking a default tech stack for answers

15 min read · last reviewed 2026-10-17

Open in the interactive app: practice, quiz, mock interview →

In one minute

How it works

The interview toolkit

Each technology below has a deep-dive lesson in this course.

RoleDefaultSwitch toWhenGo deeper
System of recordPostgreSQL or MySQLDynamoDB, Cassandra, MongoDBKey access at very high write ratesPostgreSQL, MySQL, DynamoDB, Cassandra, MongoDB, Choosing the Right Database
CacheRedisMemcachedPlain strings, multithreaded nodesRedis, Memcached
BlobsS3 (object storage)none at interview scaleNever blobs in database rowsS3
SearchElasticsearchPostgres full-text for small corporaRelevance ranking, fuzzy match, facetsElasticsearch
Task queueSQSRabbitMQRouting rules, prioritiesSQS, RabbitMQ
Event logKafkaSQS if no replay is neededPer-key order, many consumers, replayKafka
Stream processingFlinkKafka Streams, Spark Structured StreamingStateful event-time windowsFlink
Batch processingSparkSQL on a warehouseLarge joins over historySpark
ComputeContainers on KubernetesAWS LambdaSpiky, short work under 15 minutesDocker, Kubernetes, AWS Lambda
Edge and proxyNginx or a managed load balancerEnvoyMesh routing and telemetryNginx
CoordinationZooKeeper or etcdA conditional write in your databaseLeader election, small critical metadataZookeeper
MetricsPrometheusManaged equivalentsPull-based scraping, alertingPrometheus

Database choice has its own lesson, Choosing the Right Database; this chapter covers the rest of the stack and how the pieces fit together.

The default stack

Most interview systems can be drawn with six pieces: a load balancer, stateless services in containers, PostgreSQL, Redis, S3 and a queue. Starting there has two benefits. It is honest, because many real companies run exactly this far past the scale people expect. And it makes every deviation visible: when you replace Postgres with Cassandra, the interviewer hears that something in the requirements forced it, and expects you to say what.

Telling the neighbours apart

The hard choices are between tools that look similar. One property usually separates them.

Choosing under time pressure

You will not have time to compare every option. Spend comparison time only where the choice is contested or load-bearing, and state everything else as a default in one sentence. Name the tool's sharpest limit in the same breath, because that is the follow-up you will get: "SQS for thumbnail jobs, because each job is independent and we want no brokers to run; it delivers at least once, so the worker writes thumbnails to a deterministic key and duplicates are harmless."

Common mistakes

Down the stack

Layer 1The contract

Each tool makes specific promises, and the interesting ones are the edges. Kafka guarantees order within a partition, not across partitions; with acks=all and min.insync.replicas=2 on a replication factor of 3, an acknowledged write survives one broker loss. Since Kafka 3.0 the producer defaults to acks=all with idempotence on (Apache Kafka 3.0 notes), but min.insync.replicas is still a topic setting you must raise yourself. SQS standard queues deliver at least once with best-effort ordering; a received message is invisible for the visibility timeout (30 seconds by default) and reappears if not deleted, and FIFO queues deduplicate within a 5-minute window and keep order per message group, at up to 300 operations per second per partition, or 3,000 messages with batching (SQS docs). Messages can be up to 1 MiB since August 2025, up from 256 KiB (AWS). Redis replicates asynchronously, so a failover can lose writes the old primary already acknowledged; WAIT narrows but does not close that window. S3 has given strong read-after-write consistency for objects and listings since December 2020 (AWS). Elasticsearch is near real time: a document becomes searchable after the next refresh, every second by default, but a shard that has had no searches for 30 seconds skips background refreshes until the next search arrives, unless you set the interval explicitly (Elasticsearch docs). ZooKeeper linearises writes but serves reads from the connected server, which may lag unless the client calls sync first (ZooKeeper guide). Lambda runs at most 15 minutes per invocation.

Layer 2The mechanism

The contracts follow from the internals. Kafka stores each partition as append-only segment files with sparse offset indexes; followers fetch from the leader, and the in-sync replica set (ISR) decides which writes are committed. Since Kafka 4.0 (March 2025), the first release to run entirely without ZooKeeper, metadata lives in a Raft-based controller quorum (KRaft) (Kafka 4.0 release). SQS hands each receive a receipt handle and a lease; the visibility timeout is that lease. Redis runs commands on one thread around an event loop, which makes every command atomic and makes a slow KEYS * block everyone; persistence uses RDB snapshots taken by a forked child and an append-only file (AOF) with a configurable fsync policy. Elasticsearch buffers writes in memory plus a translog, and a refresh turns the buffer into a new immutable Lucene segment. Flink snapshots operator state by injecting checkpoint barriers into the stream, a variant of the Chandy-Lamport algorithm, so recovery rewinds sources to the last consistent snapshot (Flink docs). Prometheus scrapes targets and writes samples to a WAL and an in-memory head block, cut into two-hour blocks on disk and compacted into larger ones, with 15 days of retention by default (Prometheus docs).

Layer 3The machine

Kafka is fast because it does what disks and kernels are good at: batched, compressed sequential appends into the page cache, and sendfile to move bytes from page cache to socket without a user-space copy (when TLS is off), so a broker sustains hundreds of MB/s on ordinary disks. Redis keeps everything in RAM, so a lookup is a hash probe of about 100 ns plus a network round trip of a few hundred microseconds; its weak spot is fork for snapshots, where copy-on-write can nearly double memory if the write rate is high during the snapshot. Lucene maps segments with mmap, so search speed depends on the page cache holding the hot index, which is why Elasticsearch caps the JVM heap at 50 percent of RAM and now sizes it automatically by default (Elasticsearch docs). Lambda runs each function in a Firecracker microVM; a cold start is typically hundreds of milliseconds to a few seconds depending on runtime and package size. Nginx runs one worker per core, each an epoll event loop, so tens of thousands of idle keep-alive connections cost memory, not threads.

Why it's built this way

Disks are fast sequentially and slow randomly, so durable logs append and compact. Memory is fast but expensive and volatile, so caches are fast and either lose data or pay for snapshots. Coordination costs round trips, so systems push it into small dedicated services or a quorum used only for metadata. Operating a cluster is expensive in engineer time, so managed services win unless a contract they cannot meet forces you to self-host. That is why the default stack is boring and why each deviation needs a reason.

Diagram

flowchart LR
    U["Clients"] --> LB["Load balancer / Nginx"]
    LB --> API["Stateless services (K8s)"]
    API --> R["Redis cache"]
    API --> PG["PostgreSQL"]
    API --> S3["S3 blobs"]
    API --> Q["SQS tasks"]
    Q --> W["Workers"]
    PG -->|CDC| K["Kafka log"]
    K --> F["Flink aggregates"]
    K --> ES["Elasticsearch"]
    K --> SP["Spark batch"]

Worked example

The prompt: a video-sharing service with 500,000 uploads a day averaging 200 MB, 50 million daily viewers, title search, and creator dashboards showing views per minute.

  1. Uploads. 500,000 × 200 MB is 100 TB a day, straight to S3 via presigned URLs; no service touches the bytes.
  2. Metadata. About 6 new rows per second and perhaps 50,000 reads per second at peak: PostgreSQL with replicas and Redis in front. Nothing argues for a wide-column store.
  3. Transcoding. One independent, minutes-long job per upload: SQS with workers on Kubernetes, since long videos exceed Lambda's 15-minute cap. Outputs go to deterministic keys, so at-least-once delivery is safe.
  4. View counts. 500 million view events a day is about 6,000 per second on average and perhaps 30,000 at peak. Dashboards need per-minute counts and the same events feed recommendations and billing: several consumers and replay point to Kafka, per-minute windows to Flink.
  5. Search. Typo-tolerant title search points to Elasticsearch, fed from Postgres through change data capture; a second of indexing delay is fine.

Each item is one sentence plus its limit. Expect the push on item 4 ("why not increment a counter in Redis?"); that is where the comparison time goes.

In the wild

Trade-offs

OptionStrengthsWeaknessesChoose when
KafkaReplay, per-key order, many consumer groups, high throughputPartitions to plan, cluster to run, consumer lag to watchEvent streams with several consumers or a need to reprocess
SQSNo servers, scales automatically, visibility-timeout retriesNo replay, best-effort order (FIFO has throughput limits)Independent background tasks
RabbitMQFlexible routing, per-message acks, low latencyThroughput per node lower than Kafka, queues degrade when deepRouting rules, RPC-style work, priorities

Pitfalls in production

Leadership lens

Check yourself

  1. A design uses SQS for order events consumed by billing, analytics and email. Analytics later needs to reprocess last week. What went wrong?

    Show answer

    SQS deletes messages after processing, so there is no history to replay. A log such as Kafka with retention lets each consumer group re-read from an earlier offset.

  2. Why can a Redis primary failover lose writes that clients saw acknowledged?

    Show answer

    Replication is asynchronous: the primary acknowledges before replicas have the write, and a promoted replica that missed it becomes the new truth.

  3. A job takes up to 40 minutes. Lambda or containers?

    Show answer

    Containers, or split the job into steps. Lambda caps an invocation at 15 minutes.

Sources and further study

Primary

Systems docs

Books

Other curricula

Watch

Free resources

Open in the interactive app: practice, quiz, mock interview →