Everything in Backend Dev, page 10
Synchronous vs asynchronous replication trade-offs
Sync waits for replica ack giving zero data loss but higher latency; async acks immediately, faster but risks losing recent writes on failover.
Choosing a good shard key and avoiding hot spots
High cardinality, even write distribution, query alignment; monotonic keys send all writes to one shard.
When a graph database beats relational or document stores
Deeply connected data, variable-depth traversals, fraud or recommendation paths, index-free adjacency.
SQL isolation levels and the anomalies they prevent
Read Uncommitted allows dirty reads; Read Committed blocks them; Repeatable Read blocks non-repeatable reads; Serializable blocks phantoms.
Zero-downtime schema migration on a hot table
Expand-migrate-contract phases, dual-write and backfill, decouple deploys from migrations.
Tuning HNSW for recall vs latency
ANN trades exactness for speed, and HNSW knobs M and efConstruction shape graph quality while efSearch trades query latency for recall at runtime.
TSM-Tree vs LSM-Tree storage engines
Both buffer writes in memory and flush sorted immutable files, but TSM organizes by series and time with columnar, heavily compressed blocks tuned for ordered appends and range scans.
The analysis phase: tokenizers and token filters
Analysis turns raw text into index terms via a tokenizer that splits text into tokens then token filters that transform them, like lowercasing or stemming.
Vector embeddings and vector databases
An embedding is a learned dense vector capturing semantic meaning, and vector DBs use ANN indexes like HNSW for fast similarity search that relational B-trees cannot provide.
Cache-aside pattern pros and cons
App reads cache, on miss loads DB and populates, invalidates on write; pros are resilience and lean cache, cons are stale windows and app-managed invalidation.
Inverted index in search engines
An inverted index maps each term to the list of documents containing it, making keyword lookup O(1)-ish instead of scanning every document.
Iceberg vs Delta Lake metadata and ACID
Iceberg uses a tree of metadata and manifest files with atomic pointer swaps and optimistic concurrency; Delta uses an ordered transaction log of JSON commits with optimistic concurrency.
The small files problem in data lakes
Many tiny files create per-file overhead and metadata pressure, hurting scans; fix via compaction, batching writes, and tuning partitioning.
Exactly-once semantics in stream processing
Exactly-once means each event affects state once despite retries, it is hard because of failures between processing and committing, and you achieve it via idempotency or atomic…
Clickstream architecture for real-time and batch
Ingest events into a log like Kafka, fan out to a real-time path for dashboards and a batch path to a lake for ad-hoc analysis.
Schema-on-read in data lakes
Structure is applied at query time not ingest, enabling flexible raw storage and ML, but costing query-time validation and risking data swamps.
Data warehouse vs data lake
Warehouses store structured, schema-on-write data for BI; lakes store raw multi-format data with schema-on-read for exploration and ML.
Multi-region active-passive DR with Aurora
Async global replication to a passive region, promote and repoint traffic on failover, and fence the old primary to prevent split-brain.
Aurora vs Spanner architecture contrast
Aurora is single-writer with a shared distributed log-based storage and quorum, scaling reads; Spanner shards data with Paxos and TrueTime for global writes.
How Spanner achieves global external consistency
TrueTime gives bounded-uncertainty clocks via GPS and atomic sources, Spanner commit-waits out that uncertainty, and Paxos replicates each shard.
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