Memory hook: Reject any option that breaks a hard constraint before comparing convenience or price.
Must remember
- Extract availability, RPO/RTO, residency, latency, throughput, consistency, licensing, skills and cost constraints. Separate mandatory requirements from preferences. Prefer the least complex design that satisfies all mandatory constraints, not the service with the most features.
- Compare backup/restore, pilot light, warm standby and active-active using recovery time, data loss, capacity and operating complexity. Database replication is commonly asynchronous across Regions; measure lag and define promotion, write ownership and failback. Active-active writes add conflict and consistency problems.
- Map application dependencies and select migration waves. Rehost, replatform, refactor, repurchase, relocate, retain and retire have different effort and business outcomes. Application Migration Service, DMS/CDC, DataSync and transfer services move different assets; schema and application compatibility remain separate.
- Plan initial load, ongoing change capture, validation, cutover window, rollback and source retirement. A database cutover needs a strategy for writes occurring after the switch; simply pointing DNS back can lose or fork data. TTL/cache behaviour influences traffic transition.
- Modernise selectively: externalise state, decouple with queues/events, use managed data services and replace only the components whose constraints justify it. Strangler-style migration routes selected functionality to a new implementation while preserving a controlled path back.
- Improve existing systems using evidence: traces/metrics, query plans, right-sizing, caching, partitioning, autoscaling, storage lifecycle and network transfer analysis. A cache changes freshness; read replicas do not solve every write bottleneck; extra compute cannot fix lock contention.
- Compare complete solution cost, including licences, transfer, minimum storage duration, requests, support and staff effort. Test availability and recovery claims with meaningful fault/restore exercises. Record assumptions and the condition that would make the chosen design need revision.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Strict low RPO with regional disaster recovery | Choose and test a replication/recovery design that meets measured loss limits. |
| Migration deadline is short and architecture change is not required | Consider rehost/replatform before a large refactor. |
| Legacy and modern components must coexist | Incremental migration with explicit routing and data ownership. |
Traps
- Lowest operational effort is a constraint only when the question asks for it.
- A DNS failback cannot reconcile divergent writes.
- An available replica is not necessarily ready for the full production load.
Active recall
1. What should be evaluated before choosing a recovery pattern?
The acceptable data loss, outage time, operating cost and dependencies.
2. Why is dependency discovery essential?
A migration wave can break a workload if a required service remains unreachable or incompatible.
3. What makes CDC useful during migration?
It can reduce the final gap after an initial load, subject to supported engines and operational constraints.
4. Why can a read replica fail to improve database performance?
The bottleneck may be writes, locks, poor queries or traffic that still targets the writer.
5. What distinguishes a professional-level answer?
It satisfies all interacting constraints and explains migration, operation, failure and cost consequences.