Strangler Fig with serverless and an event bus

WHAT THIS TESTS This checks whether you can translate an abstract migration pattern into concrete serverless components and evolve toward event-driven architecture incrementally.

A GOOD ANSWER COVERS Recap the pattern: gradually replace the monolith behind a routing facade. In serverless terms, API Gateway is that facade. It sits in front of the legacy app and, for each route, either proxies to the monolith or invokes a new Lambda function that reimplements that feature. Initially almost everything goes to the monolith; you move features one at a time by repointing routes to Lambdas. To introduce event-driven decoupling, have the monolith or the new functions publish domain events to an event bus such as EventBridge. Consumers, additional Lambdas, subscribe to events and react asynchronously, so new capabilities attach without the monolith calling them directly. Over time more routes and more logic shift to serverless and events, and the monolith shrinks until it is retired. Address shared data and event-schema versioning during coexistence.

COMMON WRONG ANSWERS A one-shot rewrite into Lambdas with a single cutover. Omitting API Gateway, so there is no clean interception point. Skipping the event bus and tightly coupling new functions to the monolith. Ignoring shared data access between old and new systems.

LIKELY FOLLOW-UPS How do you publish events from a legacy monolith that knows nothing about EventBridge? How do you version event schemas? How do you handle the shared database? How do you roll back a migrated route?

ONE CONCRETE EXAMPLE A monolithic order app sits behind API Gateway. The team builds a new Lambda for /notifications and routes that path to it; the monolith publishes an OrderPlaced event to EventBridge, which fans out to the notification Lambda and a new analytics Lambda. Each sprint they migrate another route and emit more events, until API Gateway no longer forwards anything to the monolith and it is shut down.