A team proposes migrating an existing MySQL-backed service to MongoDB. Explain how you would decide whether the migration is justified, compare the data models and consistency needs, execute the migration safely, and prove any claimed improvement. ### Constraints & Assumptions - The current workload and schema are not yet specified, so begin with evidence to collect. - The system must remain available during migration. - A technology change is not itself a performance result. ### Clarifying Questions to Ask - Which queries, joins, transactions, and integrity constraints dominate the workload? - Is the pain write throughput, read latency, schema evolution, operational scaling, or developer workflow? - What correctness guarantees and rollback window are required? ### What a Strong Answer Covers - Workload-driven relational versus document modeling, including access patterns and aggregate boundaries. - Consistency, transactions, uniqueness, joins, schema validation, and indexing trade-offs. - A baseline benchmark and success criteria tied to production traces. - Backfill, change-data capture, shadow reads, dual-write risks, cutover, verification, and rollback. - Operational ownership, cost, failure modes, and a valid option to keep MySQL. ### Follow-up Questions - How would you model data that is read as one aggregate but updated by several independent workflows? - How would you detect missing or reordered changes during backfill? - What evidence would make you cancel the migration?