The Strangler Pattern

Last Updated: July 17, 2020

This pattern lets you route requests to your legacy APIs, while allowing you to direct specific routes to new serverless services as you add them.

Interactive Reference Architecture

Click on the components or numbered steps below to explore how this architecture works.

The Strangler is another popular pattern that lets you incrementally replace pieces of an application with new or updated services. Typically you would create some sort of a “Strangler Facade” to route your requests, but API Gateway can actually do this for us using “AWS Service Integrations” and “HTTP Integrations”. For example, an existing API (front-ended by an Elastic Load Balancer) can be routed through API Gateway using an “HTTP” integration. You can have all requests default to your legacy API, and then direct specific routes to new serverless service as you add them.

Deploy this Pattern

Below are the basic configurations for deploying this pattern using different frameworks and platforms. Additional configuration for your environment will be necessary. The source files and additional examples are available in the GitHub repo.

  • Are you a CDK Guru?
    Would you like to contribute patterns to the community?
    Check out the Github repo!

Want to Contribute?

All patterns and sample code are free to use and available under the MIT License. If you'd like to contribute to these patterns, please submit PRs to the GitHub repo.

» Explore more Serverless Reference Architectures and Patterns

4 thoughts on “The Strangler Pattern”

  1. Good day and thank you for such a usefull article. One question- how did you build these interactive diagrams with a possibility to click on components and steps to see some tooltip? It looks super powerful)

  2. Hey Jeremy, I really enjoy your posts. Between you and Yan Cui and Alex Debrie, you’re my GOTO for all things Serverless, so thanks for the great contributions. I did have a general question around design patterns, specifically around Synchronous invocations. Assume that I retained all of my public API services in one place and the Lambdas attached to that API Gateway delegated work to other Lambdas but expected to wait for the results (synchronous). A simple example might be to fetch a list of accounts for a given business (i.e. /accounts). Where I get a bit confused is around how the Lambda in API Gateway should invoke the other Lambda? I am trying to keep my account services completely separate from the API Gateway pieces and I believe you have illustrated that in other design posts you have done. Should I be exposing the account services via API Gateway (used internally), can the public API Gateway services simply invoke the Lambda directly, or should I be using Step Functions? This all becomes very tricky when it comes to testing all of this locally so I don’t need to depend on the AWS Cloud Services to do this orchestration. Do you have any recommendations or posts that explain this? Thanks again for everything!

    1. Hi Gary,

      This requires a lengthy answer, but I would not recommend adding another layer of synchronous calls to your architecture. If you are building a public facing API, you should be routing API Gateway directly to Lambda functions that do the processing required for that route. If that’s querying a database, performing some business logic, whatever, the work should be handled there. IF you have asynchronous workloads, then triggering additional processing would be possible with direct invocations using the SDK (though this creates a lot of coupling), or using an event service like SQS, SNS, EventBridge, Kinesis, etc. You may also want to trigger a Step Function for asynchronous workloads if they require highly coordinated workflows.

      Internal API design depends a lot on your organization. If you control all of the services/functions, then you may want to use the AWS SDK using the RequestResponse model. This will bypass the need for API Gateway, but will also require you to implement security, throttling, etc. yourself for those internal calls. If you want to hand off that control, putting an API Gateway in between internal calls can make a lot of sense.

      Local testing can be very difficult if you don’t set your project up correctly. I’m a big fan of using a hexagonal architecture to separate my business logic from the AWS specific layer. This lets me run my unit tests locally to harden my business logic, and then I write integration tests that run against test environments in the cloud.

      Hopefully this points you in the right direction.

      – Jeremy

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.