Strangler pattern in Martin Fowler$$s own words is $$It describes a way of doing a rewrite of an important system. Much of my career has involved rewrites of critical systems. You would think such a thing as easy $-$ just make the new one do what the old one did. Yet they are always much more complex than they seem, and overflowing with risk. The big cut$-$over date looms, the pressure is on$.$ While new features $($there are always new features$)$ are liked, old stuff has to remain. Even old bugs often need to be added to the rewritten system.

An alternative route is to gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled. Doing this sounds hard, but increasingly I think it's one of those things that isn't tried enough. In particular I've noticed a couple of basic strategies that work well. The fundamental strategy is EventInterception, which can be used to gradually move functionality to the strangler fig and to enable AssetCapture.$$

Keeping the above strategy in mind, a customer has approached you to help them in the following $-$

Take an existing application and migrate to the cloud.

Application has a web frontend, business layer, database layer, a communications$/$messaging component and a reporting layer

No new features to be developed in the existing application

New features are to be built incrementally leveraging cloud native capabilities

Appropriate routing, failover, disaster, backups etc must be planned

Release process must be in place for the existing app and new services

RTO should be less than $2$ hour and RPO should be less than $4$ hours

All features going forward are to be built incrementally leveraging cloud native capabilities and the monolithic application will not be updated.

Design the cloud architecture to meet the above client needs. You can use a cloud provider specific terms or provider agnostic terms. Eg for serverless you can use the generic term serverless or use AWS lambda$/$Cloud functions.

Additional information

Recovery Point Objective $=$ Data Risk. RPO refers to the maximum acceptable amount of data loss an application can undergo before causing measurable harm to the business.

Recovery Time Objective $=$ Downtime. RTO states how much downtime an application experiences before there is a measurable business loss.