Advanced everything in Databases & Architecture, page 2
Using page LSN to decide redo
Each page stores the LSN of its last applied change; during redo the engine reapplies a log record only if its LSN exceeds the page's LSN, meaning the change is not yet reflected on disk.
Row-oriented versus columnar storage
Row stores keep whole rows together, ideal for point reads and writes; columnar stores keep each column contiguous, enabling reading only needed columns and strong compression, ideal for scans and…
The three phases of ARIES recovery
Analysis rebuilds dirty-page and transaction tables from the last checkpoint, Redo replays all logged changes to restore state, Undo rolls back losers; Redo is idempotent via per-page LSN comparison so…
Indexing a low-cardinality status column
With three values each matches a third of rows, so the optimizer prefers a scan over costly random heap fetches; alternatives include partial indexes on rare values and composite indexes leading with status.
Optimizer picks nested loop over hash join
Nested loop wins on few rows, so bad row estimates from stale stats or skewed data trick it; fix by refreshing statistics, adding histograms, rewriting predicates, or ensuring memory for hashing.
How the write-ahead log ensures atomicity and durability
Log changes before applying, flush log at commit, replay redo and undo on recovery.
Write skew under snapshot isolation
Two transactions read an overlapping set, each writes disjoint rows, jointly violating an invariant.
Shard key impact on uniqueness and cross-shard lookups
Uniqueness and FKs hold only within a shard; non-shard-key lookups need scatter-gather or a secondary index.
Relational versus wide-column for a news feed
Relational gives flexible joins but read-time fan-out; Cassandra precomputes per-user feed rows for fast writes-side fan-out.
Polymorphic associations and referential integrity
A single column can't FK two tables, so integrity is unenforced; alternatives use exclusive arcs or per-type tables.
When to intentionally denormalize a schema
Identify read-heavy join cost, duplicate or precompute data, and own the consistency burden.
Diagnosing and fixing the N+1 query problem
Define the 1 parent plus N child queries, fix via JOIN or batched IN, and ORM eager loading.
Read Committed versus Serializable isolation levels
Name the four levels, map each anomaly (dirty read, non-repeatable read, phantom) to the level that blocks it.
HNSW: Vector Search with a Graph Highway System
HNSW finds approximate nearest neighbors in huge datasets by building a multi-layered graph, like a highway system over local roads. It's the engine in vector databases for similarity search. The footgun: it trades perfect accuracy for massive speed gains.
In-Memory Data Grid: A Shared RAM Pool for Your Cluster
An In-Memory Data Grid (IMDG) pools the RAM of multiple computers into one massive, shared data space. It's for high-speed processing on datasets too large for one machine. The footgun is mistaking it for a simple cache; it also provides parallel computation.
Continuous Queries: Automating Time-Series Aggregation
A continuous query automatically aggregates real-time data on a schedule. Use it to create downsampled rollups, like hourly averages from raw sensor data, storing results in a new series.
Approximate Nearest Neighbor (ANN) Search: Good Enough, Fast Enough
ANN search finds 'pretty close' neighbors in a massive dataset for a fraction of the cost of finding the exact closest one. It powers vector databases and semantic search.
CockroachDB: A SQL Database That Survives Disasters
CockroachDB is a distributed SQL database designed to be unkillable. Use it for global apps needing strong consistency and high availability, like financial ledgers or identity systems. The footgun: ignoring network latency between nodes can kill performance.
Google Cloud Spanner: A Globally Distributed SQL Database
Spanner is a globally distributed SQL database that scales like NoSQL but keeps the strong consistency of a relational database. Use it for global applications like financial ledgers that need ACID transactions across continents.
NewSQL: SQL Scalability Without Sacrificing ACID
NewSQL databases aim for NoSQL's horizontal scaling with the ACID guarantees of a traditional relational database. They suit high-throughput OLTP systems, like e-commerce, that must scale out. The footgun is assuming they are a simple drop-in replacement.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles