It is the combination of design patterns that matters.
A monolithic application using a single relational database goes through the following steps to reach modern architecture.
One worker process application, one database.
The first step in the strangler fig pattern is to add a strangler in front of the monolith. At the start, the strangler (proxy) routes all traffic to the monolithic application.
New features are not added to the existing monolith. You implement them as a new service (Payroll). Meanwhile, you continue fixing bugs in the monolith.
Now select one domain (Account) function inside the monolith and move it out along with the data it owns. You do not touch the monolith code yet.
The account service has been migrated to a new service. However, the transfer service calls the account service for balance checks and other functions.
To address this challenge, you implement an ACL to convert the calls to the new service contracts and route them to the appropriate service.
Modern services own their data, which means the account service stores its data in its own data store. The problem now is that existing legacy systems might need that same data for reporting and other functions.
It is time now to migrate the Email service following the same ACL approach. The difference here is that we decided to write email requests as message broker events. The legacy way of doing that is to directly contact a local SMTP server.
Once all services have been separated and traffic is routed to new services, the legacy system has no responsibilities left thus can be decommissioned.