Cloud Databases — Interview Q&A
Q: What's the actual difference between Multi-AZ and a Read Replica, and why do people confuse them?
A: They solve genuinely different problems, which is exactly why they get confused — both involve a second copy of the data in another location. Multi-AZ exists purely for high availability: a synchronously-replicated standby that automatically takes over on primary failure, but it isn't queryable directly and provides zero read-scaling benefit. A Read Replica exists purely for read scaling: it can serve read queries to offload the primary, and can be manually promoted during a disaster, but that promotion is a manual operation, not automatic failover. A system needing both availability and read scaling needs to provision both — one doesn't substitute for the other.
Q: How would you design partition key strategy for a new DynamoDB table, and what happens if you get it wrong?
A: The key decision is cardinality — choosing a partition key with enough distinct values that traffic distributes evenly across DynamoDB's internal partitions, since capacity is distributed per-partition, not just at the table level in aggregate. A low-cardinality key (a status field with only a few values, for instance) concentrates traffic onto effectively one partition, causing throttling regardless of how much total capacity is provisioned — and unlike a lot of database mistakes, this one is genuinely hard to fix after the fact without a full data migration, which is why it's worth getting right at design time rather than treating as something to tune later.
Q: When would you actually need a database with true multi-region writes, like Spanner or Cosmos DB, versus a single-primary setup with read replicas in multiple regions?
A: True multi-region writes matter specifically when write latency to a single region is a confirmed, measured problem — a genuinely global, latency-sensitive application where users in multiple continents are actively writing and cross-continent round-trip latency to one write region is unacceptable. Most applications, even ones with a genuinely global user base, are well served by a single write region with read replicas closer to users for read latency — reaching for multi-region writes just because an application is "global" without an actual measured write-latency requirement driving it is a common over-engineering trap, given the real added cost and consistency-model complexity it brings.
Q: Walk through how you'd design disaster recovery for a database, starting from the actual requirements rather than a specific technology.
A: Start from two explicit numbers, not a technology choice: RTO — how long can the system tolerably be down during a regional failure — and RPO — how much data loss, measured in time, is acceptable in that scenario. Those numbers determine the right architecture: a system that can tolerate 15-30 minutes of downtime during a rare regional failure is well served by a cross-region read replica with a tested manual promotion runbook, which is far cheaper than a full multi-region-write architecture. Building the most resilient option available regardless of actual requirements is over-engineering — the DR architecture's cost and complexity should match the genuinely required RTO/RPO, not exceed it by default.
Q: What's the real risk in a database migration, and why does it usually take longer than expected?
A: The bulk data transfer itself is usually the easy, well-automated part — tools like AWS DMS handle that largely automatically. The actual, larger risk is schema and behavior compatibility: proprietary stored procedures, vendor-specific functions, and engine-specific data types that don't have a direct equivalent in the target engine and need manual rewriting. Running a schema conversion assessment before committing to a migration timeline is what surfaces this real scope of work early — skipping that step and discovering the compatibility gaps mid-migration is one of the most common reasons a database migration runs significantly over its original schedule.
Q: Explain the tradeoff between big-bang and dual-write migration cutover strategies.
A: Big-bang means a defined maintenance window — the application stops, a final data sync completes, traffic cuts over to the new database, the application restarts. It's simpler to reason about and implement, but requires accepting real downtime proportional to that final sync's duration. Dual-write means the application writes to both the old and new databases during a transition period, gradually shifting reads to the new one as confidence builds — it avoids a hard downtime window, but is meaningfully more complex to implement correctly, since keeping both databases genuinely consistent during the transition is real engineering work with its own risk of subtle data divergence if not done carefully. The right choice depends on how much downtime is actually acceptable for that specific system — not a universal best practice either way.
Q: How would you evaluate whether vendor lock-in from a managed database like DynamoDB is an acceptable tradeoff for a given project?
A: It's a legitimate tradeoff — capability and operational simplicity in exchange for portability — not something to avoid reflexively. The practical mitigation, regardless of the decision, is isolating data-access logic behind an application-layer abstraction so a future migration, if ever needed, means rewriting an isolated layer rather than every place in the codebase that touches the database directly. Whether lock-in is actually acceptable depends on a concrete factor — does this specific product have a real, articulable multi-cloud or portability requirement (regulatory data residency, contractual portability commitments), or is that just a hypothetical future concern — and that should be decided and stated explicitly at the start of a project, not left as an unconscious default from whichever provider happened to be chosen first.