More in Databases & Architecture — page 3
Aurora vs Spanner architecture contrast
WHAT IT TESTS: deep architectural contrast. OUTLINE: 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
WHAT IT TESTS: understanding TrueTime and external consistency. OUTLINE: TrueTime gives bounded-uncertainty clocks via GPS and atomic sources, Spanner commit-waits out that uncertainty, and Paxos replicates each shard.
Cache-aside pattern with Redis and RDS
WHAT IT TESTS: knowing the lazy-loading cache pattern and its costs. OUTLINE: app checks cache, on miss reads DB and populates, writes invalidate the key, and consistency is eventual.
Near-zero-downtime database migration to cloud
WHAT IT TESTS: planning a low-downtime migration. OUTLINE: assess and provision, do a full load then continuous CDC replication with a tool like DMS, validate, then cut over with a rollback plan. RED FLAG: a one-shot dump-and-restore with a long outage.
Aurora Serverless v2 for spiky traffic
WHAT IT TESTS: matching capacity model to traffic shape. OUTLINE: Serverless v2 autoscales capacity in fine-grained ACU steps near-instantly, you pay per-ACU-second, and provisioned is fixed cost regardless of load.
Replica lag and read-your-writes consistency
WHAT IT TESTS: understanding replication lag and session consistency. OUTLINE: stale reads come from async replica lag, the guarantee a user expects is read-your-writes, and you route that user's reads to the primary after a write.
Read replica vs Multi-AZ in RDS
WHAT IT TESTS: separating high availability from read scaling. OUTLINE: Multi-AZ is synchronous standby for failover, read replicas are async copies for read throughput, and the two solve different problems. RED FLAG: claiming a Multi-AZ standby serves reads.
Managed RDS vs self-managed DB on EC2
WHAT IT TESTS: build-vs-buy operations. OUTLINE: managed RDS offloads patching, backups, failover, and replication, freeing the team to build product; self-managed EC2 means you own all that toil. RED FLAG: dismissing the hidden operational burden of DIY.
Fixing an ORM's inefficient aggregation query
WHAT IT TESTS: ORM escape hatches. OUTLINE: drop to raw SQL or a view for the heavy report, or restructure the ORM query and add indexes. Raw SQL is fast but couples to the schema; tuning keeps portability.
Unit of Work / Session pattern in ORMs
WHAT IT TESTS: ORM session mechanics. OUTLINE: the Unit of Work tracks new, dirty, and deleted objects, then flushes them as one batched transaction at commit.
Transaction isolation levels and their tradeoffs
WHAT IT TESTS: isolation tradeoffs. OUTLINE: isolation levels control which concurrency anomalies (dirty/non-repeatable reads, phantoms) are allowed; higher levels mean stronger consistency but more blocking and less concurrency.
Eager vs lazy loading in an ORM
WHAT IT TESTS: ORM loading strategy. OUTLINE: eager fetches related data up front (joins/extra query); lazy defers until accessed. Lazy in a loop causes the N+1 query problem. RED FLAG: not naming N+1 or thinking eager is always cheaper.
Pooled connection lifecycle and close() semantics
WHAT IT TESTS: pooled connection semantics. OUTLINE: borrow from pool, use, then close() returns it to the pool rather than tearing down the socket. RED FLAG: thinking close() physically severs the connection, or never closing and leaking connections.
Connection pools and the problem they solve
WHAT IT TESTS: connection reuse basics. OUTLINE: a pool reuses pre-opened connections so requests skip the expensive connect handshake; without one, every request pays setup latency and may overwhelm the database.
Purpose of database drivers (JDBC/ODBC)
WHAT IT TESTS: abstraction layers. OUTLINE: a driver translates a standard API into each database's wire protocol, so app code stays portable across vendors. RED FLAG: thinking the app talks raw protocol or that drivers are interchangeable across databases.
Defense-in-depth against SQL injection
WHAT IT TESTS: layered SQLi mitigation. OUTLINE: beyond parameterization, apply least-privilege accounts, stored procedures, input allowlisting, and monitoring to shrink blast radius. RED FLAG: treating parameterized queries as the only and complete defense.
Diagnosing degradation with normal CPU and memory
WHAT IT TESTS: wait-based diagnosis. OUTLINE: when CPU and memory look fine, sessions are waiting, not computing; examine wait statistics, lock and latch contention, I/O waits, and buffer pool hit ratio. RED FLAG: chasing CPU and memory dashboards alone.
RBAC vs direct user grants
WHAT IT TESTS: permission-management scalability. OUTLINE: direct grants tie rights to individuals; RBAC groups rights into roles users inherit, so changes happen once per role.
Point-in-Time Recovery (PITR)
WHAT IT TESTS: recovery design. OUTLINE: restore a base backup then replay archived write-ahead logs up to a chosen moment, enabling recovery to just before an error. RED FLAG: thinking periodic backups alone allow recovery to any instant.
Connection pooling and its key parameters
WHAT IT TESTS: pooling tradeoffs. OUTLINE: reuse open connections to skip costly handshakes; tune max pool size and connection timeout. RED FLAG: setting max size huge, exhausting database connections, or treating the pool as free.