Interview questions

Try each one before you open the answer.

What durable means, and the log

1What does it mean for a write to be durable?

It is stored on something that survives the failures you care about. "Durable" is not one thing but a position on a ladder: from the operating system's page cache (survives a process crash), to the device, to other machines, up to verified copies in several independent failure domains. A claim of durability is only meaningful once you say which rung.

Fsync and group commit

8A database has one log, and flushing it takes 1 ms. What is the maximum commit rate, and how do you raise it?

If every commit waits for its own flush, at most 1,000 commits per second (Little's Law: one in flight, 1 ms each). Raise it with group commit: commits that arrive while one flush is running share the next flush, so the cost of a flush is spread over many commits.

Checkpoints, backups and retention

13Why do databases rarely use a sharp checkpoint, one that writes all dirty pages at once?

Because it causes a periodic stall: writing 20 GB of dirty pages at 1 GB/s blocks the database for 20 seconds. A steady, predictable cost is worth more than a smaller cost that arrives in spikes.

Corruption and replication

21What is a torn page, and how do database engines prevent it?

A page that is part old and part new after a crash, because the device writes atomically in units smaller than the database's page (for example 4 KB sectors under a 16 KB page). Engines prevent it with a double-write buffer (MySQL), full-page images in the log (PostgreSQL), or a device that guarantees atomic page-sized writes.

22Why is a checksum stored inside a block not enough to detect corruption?

A write that lands in the wrong place brings its own valid checksum with it, so the misplaced block looks fine. The checksum must also cover the block's identity (which block it is supposed to be), and be stored outside the block, for example in the parent pointer.

23How often must you scrub (re-read and verify) stored data?

Often enough that you find corruption while a good copy still exists: scrub period + alerting delay < retention of the last good copy. With 14 days of backups and a 1-day alert lag, scrub at least every 13 days.

24In a quorum system, why does W + R > N not tell you how many failures your data survives?

That rule is about reads overlapping writes, so a read sees the latest acknowledged write. Durability depends on W, the number of copies that existed when the write was acknowledged, and on whether those copies sit in independent failure domains.

25What is the idea behind copysets in replica placement?

Limit the number of distinct sets of nodes that hold replicas together, so that a simultaneous failure of, say, any 3 nodes is less likely to hold every replica of some partition. It trades how often data is lost for how much is lost when it happens.

Durability across a pipeline

27With acks=all, can a Kafka producer still lose an acknowledged record?

Yes, in two ways. "All" means every in-sync replica, and that set can shrink to the leader alone: with the default min.insync.replicas=1, the acknowledgement then means one machine has the record in memory. And no broker flushes per message by default, so a power cut that takes every replica at once loses records they all acknowledged. Set min.insync.replicas=2 so the shrunken case becomes an error the producer sees, keep unclean leader election off, and put the replicas in independent failure domains.