Retail Order System: Lift-and-Shift Versus Container Platform
Northwind Outfitters runs a Java/Spring order-management monolith on 12 Compute Engine VMs and an 8 TB Oracle 11g database. The system serves 450 stores and peaks at 12,000 orders per hour; Black Friday is expected to be five times normal. Oracle licensing expires in six months. Leadership wants migration to Google Cloud with a 30-minute RTO and 5-minute RPO. The team has basic Docker knowledge but no production Kubernetes experience. The application keeps HTTP sessions in memory and uses several Oracle-specific stored procedures. Security requires PII encryption at rest and in transit, private connectivity to the database, and no public IPs on database servers. Finance has capped the first-year run rate near the current on-premises cost, so a large multi-region Spanner commitment is unlikely to be approved. A consulting partner can help for 10 weeks but will leave after cutover. You must choose a target platform and database, define the migration path, and leave the internal team able to operate it.
1. Recommend a target compute and database architecture for the migration. Justify your choice against at least two alternatives and state the main trade-off.
Read the worked answer
Size the problem first
12,000 orders/hour is about 3.3 orders/second; a 5x peak is about 17 orders/second. That is not a hyperscale write workload. The decision is driven by Oracle-specific code, in-memory sessions, team skills, and the 30-minute RTO / 5-minute RPO, not raw throughput.
Compute recommendation
Use a regional Compute Engine managed instance group behind a global external HTTPS load balancer: an instance template, autoscaling, health checks, rolling updates, and a blue/green or canary deployment process. This is a lift-and-shift with managed operations. It preserves the monolith and session handling, which the team can support, and avoids forcing a Kubernetes learning curve before cutover.
Database recommendation
Use Cloud SQL for PostgreSQL Enterprise Plus with 8 TB storage, private IP, HA, CMEK, and a cross-region read replica. Convert Oracle stored procedures to PostgreSQL functions or application code. Cloud SQL meets the capacity, gives managed backups and point-in-time recovery, and keeps cost below Spanner.
Alternatives and trade-off
- GKE Autopilot gives better portability and bin packing, but requires production Kubernetes skills, session externalization, and new deployment practices. That is too much change in six months.
- Cloud Run is attractive for stateless services, but the in-memory sessions and long-running monolith would need refactoring; request timeouts and connection behavior add risk.
- Spanner provides global strong consistency, but the Oracle rewrite, multi-region cost, and operational model are not justified at 17 orders/second.
- AlloyDB may outperform Cloud SQL for analytics-heavy workloads, but the team lacks experience and the workload is transactional.
The main trade-off is that the MIG plus Cloud SQL design is less cloud-native and does not force session externalization now. In exchange, it is operable by the current team within the deadline. The 5-minute RPO depends on measured replication lag; rehearse promotion and add WAL archiving or a different replication design if lag cannot be held under five minutes.
2. Design the database migration and cutover plan. How do you minimize downtime, validate correctness, and preserve a rollback path?
Read the worked answer
Migration phases
- Inventory and convert: catalog Oracle schemas, sequences, triggers, and stored procedures. Use a schema-conversion tool plus manual review for Oracle-specific constructs. Run the converted schema in a lower environment.
- Initial load and CDC: use Database Migration Service or a CDC tool to perform a full load and continuous replication from Oracle to Cloud SQL for PostgreSQL. Keep Oracle authoritative until cutover.
- Validation: compare row counts, key aggregates, and checksums per table. Run the application test suite against a read-only Cloud SQL copy. Replay a production-like order stream at 5x peak to measure latency and replication lag.
- Dress rehearsal: perform at least two cutover rehearsals, including DNS/connection-string change, rollback, and timed RTO/RPO measurement.
Cutover window
Freeze writes or put the order application into maintenance mode. Let replication catch up, verify lag is zero and checksums match, then switch the application connection string through a controlled change. Keep Oracle read-only and replication available for 72 hours. If validation fails, switch back to Oracle using the documented reverse procedure.
Correctness and rollback details
- Automate pre- and post-cutover checks so validation is not manual guesswork.
- Use a canary group of stores before all 450 stores.
- Monitor error rates, order completion, database connections, and replication lag during the first peak cycle.
- Document the exact rollback trigger, owner, and communication path. A rollback path that has not been rehearsed is not a real rollback path.
3. What operating model, monitoring, and skills-transition steps would you put in place so the internal team can run the platform after the partner leaves?
Read the worked answer
Operate by design, not by handover document
Put compute, networking, IAM, and Cloud SQL configuration in Terraform so changes are reviewable. Define SLOs for order submission latency and success rate, and alert on symptoms: HTTP 5xx rate, p95 latency, database CPU, connection saturation, replication lag, backup failures, and failover events.
Runbooks and game days
Write runbooks for database failover, replica promotion, backup restore, certificate rotation, scaling events, and rollback. Run at least one failover game day and one backup-restore game day with the internal team leading and the partner observing. Record actual RTO and RPO and fix gaps before decommissioning Oracle.
Skills transition
Pair the partner with two internal engineers per area: Cloud SQL/PostgreSQL, networking/load balancing, and operations/observability. Require the internal team to perform the second cutover rehearsal. Train on PostgreSQL query tuning and stored-procedure changes, not just Google Cloud console clicks.
Security and cost controls
Use private IP, CMEK, TLS, least-privilege IAM, and no service account keys. Add budget alerts and cost labels. Review backups and retention. The goal is a team that can diagnose an order failure at 02:00 without the partner and can explain why each control exists.