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
• [done] LSM trees vs B-trees: the three amplifications
• [done] Compaction strategies: STCS, LCS, TWCS, and how to pick
• [done] RocksDB tuning: block cache, bloom filters, write stalls
• [done] Cassandra data modelling, query-first, worked
• [done] Tunable consistency, repair mechanisms and gc_grace_seconds
• [done] PostgreSQL MVCC, bloat, autovacuum and XID wraparound
• [done] Reading a Postgres query plan
• [done] PgBouncer transaction pooling, and what it breaks
• [done] GSIs vs LSIs, sparse indexes, hot partitions and write sharding
• [done] Iceberg table lifecycle: snapshots, hidden partitioning, small files
• [done] DynamoDB single-table design
• [done] Zero-downtime reindex in OpenSearch
• [done] Choosing a MongoDB shard key
• [done] Online schema change
• [done] Choosing a database

Source: §20, §46.