Storage and data platform
Partition key choice is where most system designs live or die, and it is the first thing a good interviewer probes. This chapter covers the engines (LSM vs B-tree, and what compaction actually costs you), the four stores you will be asked to model in (DynamoDB, Cassandra, MongoDB, PostgreSQL), the search engine you probably operate (OpenSearch), and the analytics layer that increasingly sits behind AI features.
The habit worth building: say "access patterns first, schema second" before you draw anything, then show the access patterns as a numbered list, then design the key. Interviewers listening for a staff signal are listening for that ordering.
What this chapter covers
- [done] Cassandra tombstones and the range-scan timeout
- [todo] LSM trees vs B-trees: write amplification, read amplification, space amplification
- [todo] Compaction strategies: STCS, LCS, TWCS, and how to pick
- [todo] RocksDB tuning: block cache, bloom filters, write stalls
- [done] DynamoDB single-table design
- [todo] GSIs vs LSIs, sparse indexes, hot partitions and write sharding
- [todo] Cassandra data modelling, query-first, with a worked example
- [todo] Tunable consistency, repair, and gc_grace_seconds
- [done] Choosing a MongoDB shard key
- [todo] PostgreSQL MVCC, bloat, autovacuum and XID wraparound
- [todo] Reading a Postgres query plan
- [todo] PgBouncer transaction pooling and what it breaks
- [todo] Online schema change: expand-contract, CREATE INDEX CONCURRENTLY, gh-ost
- [done] Zero-downtime reindex in OpenSearch
- [todo] Iceberg table lifecycle: snapshots, hidden partitioning, small files
- [todo] Choosing a database: the decision walkthrough
Source: §20, §46.