During a migration from a monolith to microservices on Google Cloud, which database strategy minimizes downtime while preserving the option to adopt service specific data stores later?

Question

Options

• AMigrate to Cloud Spanner now and split schemas by service
• BRefactor into microservices while all services keep using the single database for now
• CCreate one database per service and cut over all services in one release
• DAdd a data access layer service that proxies all database calls

• B
  64% (9)
• C
  14% (2)
• D
  21% (3)

Explanation

This is the Strangler Fig / shared-database-first pattern. Decomposing application logic into microservices first-while keeping the shared database unchanged-limits the blast radius of each change: no schema splits, no data migrations, and no dual-write complexity occur during the initial cut. Once services are independently deployed and their boundaries are proven stable, each team can extract its own schema or switch to a purpose-fit data store incrementally. Option A requires a full schema redesign and Spanner migration up front, creating large downtime risk. Option C forces a risky big-bang cutover. Option D adds an abstraction layer but does not actually reduce migration risk or preserve flexibility.

No community discussion yet for this question.