Databases and Storage

Database interviews test whether you can choose storage, model data, and operate systems under real constraints—not recite vendor slogans. Strong answers start from access patterns, invariants, write rate, read latency, data size, and failure modes before naming PostgreSQL, MongoDB, Redis, or Elasticsearch.

This domain spans SQL fundamentals, relational engines (PostgreSQL, MySQL, SQLite), document and cache stores (MongoDB, Redis), search engines, optional vector storage, and data-engineering basics (OLTP vs OLAP, replication, CDC, pipelines).

On interviews: for a product feature, name what must be strongly consistent, what may be stale, which indexes or document shapes serve the hot path, and what breaks during migration, vacuum, replication lag, or cache invalidation.

Common pitfalls: choosing a database by popularity; indexes without query plans; hiding relational invariants in application code; using caches as a correctness layer; ignoring backups, replication lag, and lock behavior.

The trade-off is balancing consistency, latency, operability, and team familiarity — name which axis you optimized and what cost you accepted.

Checklist:

• Start from access pattern and invariant, not technology logo.
• Separate transactional serving from analytics and search.
• Plan indexes, migrations, and operational failure modes.
• Use child topics for engine-specific depth.