SYSTEM DESIGN · TRACK 2
Technologies
The databases, caches, logs and stores that show up in every design, and how to pick between them: data model, internals, scaling, strengths, weak spots and the numbers worth knowing.
All 12 are live. Each one is an animated walkthrough you can step through, written notes, and the interview questions with answers.
- 1 PostgreSQLWhat PostgreSQL is and why it is the safe default for most designs: tables and constraints, the write-ahead log, MVCC row versions and vacuum, B-tree, GIN and BRIN indexes, connection pooling, streaming replication and failover, partitioning and sharding with Citus, where it hurts, the numbers worth knowing and how to justify it in an interview.
- 2 MySQLHow MySQL with InnoDB stores rows in a clustered primary-key index, why secondary lookups cost two trips, redo and undo logs, the binlog and replica fan-out, repeatable read and gap locks, why random UUID keys slow inserts, scaling with replicas, ProxySQL and Vitess, where it hurts and how to justify it in an interview.
- 3 MongoDBHow MongoDB stores JSON-like documents, when to embed and when to reference, the WiredTiger engine and indexes, replica sets with elections, write and read concerns, sharding through mongos with ranged or hashed shard keys, multi-document transactions, the traps that hurt in production and how to justify it in an interview.
- 4 CassandraHow Apache Cassandra spreads data over a token ring with no leader, partition keys and clustering columns, the commit log, memtable and SSTable write path, bloom filters and compaction on reads, tunable consistency with LOCAL_QUORUM, tombstones and repair, modelling one table per query, where it hurts and how to justify it in an interview.
- 5 DynamoDBHow Amazon DynamoDB stores items by partition key and sort key, how requests are routed to partitions with three replicas, capacity units and the per-partition limits behind hot keys, strong versus eventual reads, global and local secondary indexes, single-table design, transactions, streams, global tables, where it hurts and how to justify it in an interview.
- 6 RedisWhat Redis is and why it is so fast: in-memory data structures served by a single command thread, strings, hashes, sorted sets and streams, TTLs and eviction, RDB and AOF persistence, replication with Sentinel, Redis Cluster hash slots, the patterns it powers (cache-aside, rate limits, leaderboards, locks), where it hurts and the numbers to quote.
- 7 KafkaHow Apache Kafka works as a replicated, partitioned, append-only log: topics, partitions and offsets, keys and ordering, why sequential disk and batching make it fast, leaders, in-sync replicas and acks=all, consumer groups and rebalancing, retention and compaction, exactly-once, KRaft, where it hurts and how to place it in an interview design.
- 8 ElasticsearchHow Elasticsearch turns documents into an inverted index, what analyzers do, the refresh and translog write path behind near real-time search, primary and replica shards, query-then-fetch across shards, BM25 relevance, aggregations, keeping it in sync with your database, deep pagination, where it hurts and how to place it in an interview design.
- 9 ZooKeeper and etcdWhat coordination services are for and why they sit beside your real databases: ZooKeeper znodes and etcd keys, consensus with ZAB and Raft, why ensembles have 3 or 5 members, sessions and leases, watches, leader election, locks with fencing tokens, service discovery and configuration, the size and throughput limits, and how to use them in an interview.
- 10 S3-style object storageHow S3-style object storage works: buckets, keys and immutable objects, metadata and erasure-coded data behind the API, strong read-after-write consistency, presigned URLs for direct uploads, multipart uploads, per-prefix request rates, storage classes and lifecycle rules, events and CDNs, where it hurts, the numbers worth knowing and how to use it in an interview.
- 11 ClickHouse and time-series storesWhy analytics needs column-oriented storage: reading only the columns a query needs, compression and vectorised execution, ClickHouse MergeTree parts, sorting keys and sparse indexes, batched inserts, materialized-view rollups, sharding and replication, how time-series databases store labelled samples, the cardinality trap, where they hurt and how to use them in an interview.
- 12 Which database? A decision tableA decision guide for choosing storage in a design interview: the four questions to ask (access pattern, consistency, scale, data shape), why a relational database is the default, the thresholds that justify something else, a side-by-side comparison of PostgreSQL, MySQL, MongoDB, Cassandra, DynamoDB, Redis, Kafka, Elasticsearch, etcd, object storage and ClickHouse, common pairings and the mistakes to avoid.
Next: Building Blocks
Load balancer, cache, queue, key-value store: one component at a time.