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

Question

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?

Answer 1

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.

Answer 2

I will be surprised if anyone says that there is a right and wrong answer.

I've done both in different projects, I guess it comes down to the CICD preferences, architecture, time constraints.

Having one lambda theoretically simplifies your architecture but effectively you're building a monolithic app with all the downsides applicable to that architecture, however, if you're single dev it significantly minimises building, testing and deployment process, so you don't have to worry about dependencies between lambdas and have a single deployable artifact.

On the other hand, multiple lambda functions offer you the flexibility similar to microservices, but it would require you to have individual pipelines and the whole CICD ecosystem becomes more complex and time-consuming.

On more thing to be mindful when having all code in one lambda function, is the size limit and potential dependency hell, depending on your language.

Not knowing your organisation/project and time constraints, I would probably start with a single lambda and split it into multiple lambda functions later if needed...