More in Backend Dev — page 11
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.
Least privilege for database service accounts
WHAT IT TESTS: secure access design. OUTLINE: grant each account only the minimum rights its job needs; for an app service account, scope grants to specific tables and verbs, never use the superuser.
Full, differential, and incremental backups
WHAT IT TESTS: backup-strategy tradeoffs. OUTLINE: full copies everything; differential copies all changes since the last full; incremental copies changes since the last backup of any type.
Mitigating a database shard hot spot
WHAT IT TESTS: load-distribution remedies. OUTLINE: short-term, add read replicas or cache the hot keys; long-term, fix the partition key with hashing, salting, or finer-grained splitting. RED FLAG: only adding hardware without addressing the skewed key.
Split-brain, consensus, and quorum
WHAT IT TESTS: partition handling. OUTLINE: split-brain is two nodes both believing they are leader during a partition; Raft/Paxos require a majority quorum to elect a leader and commit, so the minority side cannot make progress.