Question

Difficulty: MediumManaging Technology Debt and Legacy Cloud Migrations

A pharmaceutical research institute is migrating a legacy monolithic clinical trial application from an on-premises data center to Google Cloud. The legacy system relies on an on-premises PostgreSQL database that suffers from technical debt, specifically unnormalized tables accessed directly by multiple legacy modules. The institute must refactor the database into domain-driven data structures and migrate to Cloud SQL for PostgreSQL without introducing downtime or breaking existing regulatory reporting dependencies during the transition period. Which strategy best addresses the technical debt while satisfying the migration constraints?

  1. Apply the expand-contract pattern by introducing backward-compatible views in PostgreSQL, continuously replicate data to Cloud SQL using Database Migration Service (DMS), and incrementally transition microservices to the new schema before removing legacy structures.Answer
  2. B
    Refactor all unnormalized tables directly into a globally distributed Cloud Spanner database schema, and use continuous CDC replication to sync data prior to a single-cutover migration.
  3. C
    Perform a breaking schema refactor directly on the target Cloud SQL database, followed by a blue-green application deployment that immediately redirects all legacy and microservice traffic to the new schema.
  4. D
    Containerize the monolithic application, deploy it to a Google Kubernetes Engine (GKE) cluster, and run independent PostgreSQL container pods per microservice using an offline database export and import.

Answer

Apply the expand-contract pattern by introducing backward-compatible views in PostgreSQL, continuously replicate data to Cloud SQL using Database Migration Service (DMS), and incrementally transition microservices to the new schema before removing legacy structures.
The correct strategy combines the expand-contract database refactoring pattern with continuous replication via Database Migration Service (DMS). Creating backward-compatible views ensures existing legacy reporting applications continue to function without breaking, while microservices are incrementally migrated. Database Migration Service ensures real-time data synchronization between on-premises PostgreSQL and Cloud SQL with minimal downtime.

Step-by-Step Solution

1
Analyze technical debt and reporting constraints
Identify that legacy reporting modules cannot tolerate breaking database schema changes during migration.
Direct schema changes cause immediate failures in un-refactored modules.
2
Implement database schema decoupling strategy
Apply the expand-contract (parallel change) pattern using backward-compatible views.
Allows new domain microservices to read/write modern schemas while legacy components continue operating against legacy table structures.
3
Establish continuous data replication and incremental cutover
Use Database Migration Service (DMS) for continuous PostgreSQL replication to Cloud SQL with zero downtime.
Ensures data parity across on-premises and cloud environments until all legacy dependencies are retired.

Key Concept

Managing Database Technical Debt during Migrations using Expand-Contract Pattern and Database Migration Service
Rate this question