Search code examples
amazon-web-servicesapiaws-lambdaapi-design

Is it better to have 1 Lambda function per route? or 1 Lambda that handles child routes?

If I have an API that has the following routes

POST /slack
POST /slack/hook
POST /slack/another-hook
POST /slack/hook/nested

Is it better to have 4 separate Lambda functions and 4 routes in the API Gateway? Or to have 1 Lambda for the root route and have the Lambda handle the routing from there?

example 1

POST /slack --> lambda1
POST /slack/hook --> lambda2
POST /slack/another-hook --> lambda3
POST /slack/hook/nested --> lambda4

example 2

POST /slack --> lambda1
POST /slack/hook --> lambda1
POST /slack/another-hook --> lambda1
POST /slack/hook/nested --> lambda1

Is there a best practice for this? If so why?

Solution

  • This blog post here explains the pros and cons of various serverless patterns. Following are some things to keep in mind:

    One Lambda per route aka microservice pattern:

    Pros

    • Easier to debug since each lambda has a very specific function and cloudwatch logs are well separated.
    • Easier to test since each lambda handles a separate event.
    • Deployments are more fine grained. Updating a function can only affect a specific functionality so you have a separation of concerns.

    Cons

    • Possibly more cold starts for lambdas since some of them might not be frequently accessed.

    • You might end up with a lot of lambda functions to manage.

    • Slower deployments as there are multiple functions to deploy.
    • You might run into the cloudformation resource limit for a single stack(which is 200 resources) pretty soon. I have run into this personally.

    One Lambda with multiple routes aka service/monolith pattern depending how routes are grouped:

    Pros

    • Fewer cold starts/better performance since the lambda would be invoked frequently and stay warm.
    • Fewer lambda functions to manage.
    • Faster deployments as there are fewer functions to deploy.

    Cons

    • Harder to debug and analyse cloudwatch logs, function handles multiple types of events.
    • You need to write and maintain a router.
    • Bigger function size so you could hit the deployment size limit.
    • Updating a function might cause regression and break some other functionality.

    As you can see, there are pros and cons to each approach and there is no single right way to do things. Also as the other answer suggests, you need to consider things like CICD, project and time constraints as well.