Strangler Fig Pattern

// Strangler Fig migration phases
//
// Phase 1: Proxy in front of monolith (everything goes to monolith)
// Client → API Gateway → Monolith (all endpoints)
//
// Phase 2: Extract UserService
// Client → API Gateway
//   /api/users/**  → NEW UserService (microservice)
//   /api/*         → Monolith (everything else)
//
// Phase 3: Extract OrderService
// Client → API Gateway
//   /api/users/**  → UserService
//   /api/orders/** → NEW OrderService
//   /api/*         → Monolith (shrinking)
//
// Phase N: Monolith is empty → decommission
// Client → API Gateway → All microservices

// NGINX routing during migration
upstream monolith { server monolith:8080; }
upstream user_service { server user-svc:8080; }
upstream order_service { server order-svc:8080; }

server {
    location /api/users/ { proxy_pass http://user_service; }
    location /api/orders/ { proxy_pass http://order_service; }
    location / { proxy_pass http://monolith; }  # default: monolith
}

// Database migration strategy
//
// Step 1: New service reads from monolith DB (shared, temporary)
// Step 2: New service gets its own DB
//         CDC (Debezium) syncs monolith DB → new service DB
// Step 3: New service reads/writes its own DB
//         Verify data consistency
// Step 4: Remove CDC sync, decommission monolith tables

// Debezium CDC — sync monolith → new service
{
  "name": "users-cdc",
  "config": {
    "connector.class": "io.debezium.connector.mysql.MySqlConnector",
    "database.hostname": "monolith-db",
    "database.include.list": "monolith",
    "table.include.list": "monolith.users,monolith.user_profiles",
    "topic.prefix": "migration"
  }
}
// Kafka topic: migration.monolith.users
// New UserService consumes → populates users_db