A media company runs a monolithic ticketing app on EC2 with tight coupling and scaling bottlenecks during premieres. It must incrementally extract showtime and payment features to serverless microservices with no big-bang rewrite and safely retire legacy paths after validation. Which refactor approach enables incremental modernization with lowest risk?

The strangler fig pattern is correct because it places a routing facade over the monolith and incrementally intercepts showtime and payment calls, directing validated traffic to new Lambda and API Gateway services while legacy paths remain as fallback until metrics confirm parity, which directly satisfies serverless extraction, avoids big-bang risk and enables safe retirement. The EKS microservices with weighted ALB routing fails by platform concept because although it is incremental and supports validation, it delivers containers on Kubernetes rather than the mandated serverless Lambda model, leaving scaling operations and premiere burst handling misaligned. The parallel Lambda build followed by a single cutover fails by migration concept because although it targets the correct serverless services, replacing gradual routing with one traffic switch reintroduces big-bang blast radius and prevents per-feature rollback after validation. The modular monolith with feature flags on EC2 fails by architecture concept because although it reduces coupling and allows safe validation, it never extracts to independent serverless microservices and therefore preserves deployment scaling bottlenecks. Exam caveat is to distinguish incremental delivery from incremental platform, as many patterns sound gradual but only strangler combined with serverless satisfies all stem constraints together. Practical check is to verify routing telemetry, canary error budgets and legacy decommission criteria for each endpoint before retiring code.