When Tradition Becomes an Anti-Pattern or the argumentum ad antiquitatem fallacy

Updated: at 10:12 AM (8 min read)

When Tradition Becomes an Anti-Pattern: Introducing the Lambda-lyth Approach

Table of contents

Open Table of contents

Appeal to Tradition

Many AWS users still follow a “multiple-Lambda-per-route” pattern, assuming each route in REST API Gateway must map to a separate Lambda. This is often justified with “that’s how everyone does it.” However, tradition alone isn’t proof that a pattern remains efficient or optimal, and new approaches can reduce resource sprawl and operational overhead.

Drawbacks of Multiple-Lambda-per-Route

  1. Resource explosion: Each route adds another Lambda, IAM role, and CloudFormation resource.
  2. Scattered logging: Logs separate across multiple functions.
  3. Inconsistent error handling: Different Lambdas may implement different strategies.
  4. Complex permissions: Multiple Lambdas increase IAM friction.
  5. Maintenance overhead: Every new route can add more infrastructure code to manage.

Lambda-lyth in a Nutshell

Lambda-lyth is a single-Lambda approach that leverages an API Gateway “proxy+” integration. Traffic hits one Lambda function, which routes requests internally. This centralizes routing, reduces resource sprawl, and lowers operational complexity without sacrificing best practices.

Architectural Overview API Gateway One resource: ANY /{proxy+} A single integration that points to the “Router Lambda.” Router Lambda Central piece of logic that inspects the incoming path and HTTP method. Uses a custom or third-party router to delegate requests. Business Logic Handlers Grouped by domain (e.g., todos, users, etc.). Enforced by a neat directory structure. Minimal Infrastructure Typically one DynamoDB table (or a few) for data persistence. Fewer AWS resources in your CloudFormation stack. The Name “Lambda-lyth” Think of a “monolith,” but for serverless. While the microservices approach suggests multiple Lambdas, Lambda-lyth is a single Lambda with modular code that can grow without spawning countless AWS resources.

Three Example Implementations

Three repositories to illustrate how Lambda-lyth can be done in different ways:

Node.js In-House Code Handler

A custom router written in TypeScript (or JavaScript), demonstrating a straightforward approach. Showcases how to define routes, parse parameters, and handle different endpoints. Node.js Hono Handler

import {
  APIGatewayProxyEvent,
  APIGatewayProxyResult,
  Context,
} from "aws-lambda";
import { Logger } from "@aws-lambda-powertools/logger";
import { todosRouter } from "./routes/todos";

const logger = new Logger({
  serviceName: "api-router",
});

export const handler = async (
  event: APIGatewayProxyEvent,
  context: Context
): Promise<APIGatewayProxyResult> => {
  try {
    logger.info("Processing request", {
      path: event.path,
      method: event.httpMethod,
    });
    return await todosRouter.handle(event);
  } catch (error) {
    logger.error("Unhandled error", { error });
    return {
      statusCode: 500,
      body: JSON.stringify({
        message: "Internal Server Error",
        requestId: context.awsRequestId,
      }),
    };
  }
};

Node.js Hono router

Offers an Express-like experience for route definitions, middlewares, and error handling, all within a single Lambda. Python AWS Lambda Powertools

import { Hono } from "hono";
import { handle } from "hono/aws-lambda";
import {
  getTodos,
  getTodoById,
  createTodo,
  updateTodo,
  deleteTodo,
  getTodosByStatus,
} from "./handlers/todos";

const app = new Hono();

// Todo routes
app.get("/todos", getTodos);
app.get("/todos/status/:completed", getTodosByStatus);
app.get("/todos/:id", getTodoById);
app.post("/todos", createTodo);
app.patch("/todos/:id", updateTodo);
app.delete("/todos/:id", deleteTodo);

export const handler = handle(app);

Uses the APIGatewayRestResolver from AWS Lambda Powertools (Python version).

Demonstrates how to elegantly build REST APIs with built-in observability, tracing, and input validation. Note: The Node.js version of APIGatewayRestResolver is planned on the roadmap but not yet available. These examples prove that Lambda-lyth is not a one-size-fits-all concept limited to one language or one particular library—it’s an architectural pattern that can be realized in multiple ways, each preserving the single-Lambda approach.

from aws_lambda_powertools import Logger, Metrics, Tracer
from aws_lambda_powertools.event_handler import APIGatewayRestResolver
from aws_lambda_powertools.utilities.typing import LambdaContext
from aws_lambda_powertools.logging import correlation_paths

logger = Logger()
tracer = Tracer()
metrics = Metrics(namespace="TodosAPI")
app = APIGatewayRestResolver()

# Import your route modules
from todos import register_routes
register_routes(app)

@logger.inject_lambda_context(correlation_id_path=correlation_paths.API_GATEWAY_REST)
@tracer.capture_lambda_handler
@metrics.log_metrics(capture_cold_start_metric=True)
def handler(event: dict, context: LambdaContext) -> dict:
    try:
        return app.resolve(event, context)
    except Exception as e:
        logger.exception("Error processing request")
        return {
            "statusCode": 500,
            "body": '{"message": "Internal Server Error"}',
            "headers": {
                "Content-Type": "application/json"
            }
        }

Infrastructure Setup:

import * as cdk from "aws-cdk-lib";
import { NodeApiHonoStack } from "../lib/node-api-hono-stack";

const app = new cdk.App();
new NodeApiHonoStack(app, "NodeApiHonoStack", {
  // Pass shared resources like DynamoDB table here
});

app.synth();

Key Architectural Benefits

Dramatically fewer CloudFormation resources. Lower risk of hitting the 500-resource limit.

Centralized logging, metrics, and traces. One place to implement cross-cutting concerns like authentication, caching, and error handling.

Because there’s only one Lambda function, you can leverage AWS Lambda’s “warm start” (or “thaw”) behavior more effectively. For example, database connection pooling is simpler when your code runs in a single Lambda function, allowing better reuse of connections across invocations. This can reduce latency and costs since you aren’t recreating database clients for each route’s separate Lambda.

Adding a new route doesn’t mean provisioning a new Lambda function. Quicker iteration and simpler CI/CD pipelines.

A monorepo structure enforces consistent architecture and best practices. TypeScript or Python code is easier to maintain and test in one Lambda “hub.”

How to Implement Lambda-lyth

Step 1: API Gateway Setup

Copy code
const api = new apigateway.RestApi(this, "MyApi");
const routerFunction = new nodeLambda.NodejsFunction(this, "RouterHandler");
api.root.addProxy({
defaultIntegration: new apigateway.LambdaIntegration(routerFunction),
});

Only one REST API resource: ANY /{proxy+}. Directs all incoming requests to RouterHandler.

Step 2: Implement the “Router” Lambda

For a Node.js in-house approach:

Copy code
// router.ts
class Router {
private routes: Route[] = [];

public get(path: string, handler: RouteHandler) {
this.addRoute("GET", path, handler);
}
// ...
}

export const router = new Router();

// Example route
router.get("/todos", async () => {
const todos = await todoEntity.scan.go();
return {
statusCode: 200,
body: JSON.stringify(todos),
};
});

Routes are defined in one place. Path parameters and HTTP methods are easily managed.

Step 3: Business Logic and Persistence

Use ElectroDB or AWS SDK for DynamoDB. Keep your data operations type-safe and succinct. You still get the modularity of multiple “services” at the code level, but physically it’s one Lambda. Step 4: Testing and Local Development Unit Tests: Run Jest or PyTest on route handlers. Integration Tests: Mock the event payload to ensure the Router function interprets it correctly.

Cross-Cutting Concerns

Logging

Use a single logger instance (e.g., AWS Lambda Powertools Logger) in Python or a popular library like winston in Node.js. Error Handling

Copy code
export const handler = async (event: APIGatewayEvent) => {
try {
return await router.handle(event);
} catch (error) {
console.error("Unhandled error", error);
return {
statusCode: 500,
body: JSON.stringify({ message: "Internal Server Error" }),
};
}
};

Authentication/Authorization

Add a middleware layer that checks tokens/permissions. Consistent logic for all routes. Observability (Tracing & Metrics)

AWS X-Ray or AWS Lambda Powertools Tracer can instrument the entire Lambda, no matter the route.

Performance and Cost

Cold Starts: One function means you have fewer cold starts overall than multiple smaller Lambdas.

Routing Overhead:

Matching a route in memory is extremely fast; it’s negligible compared to network latency.

Cost Optimization:

You’re not paying for multiple idle Lambdas. A single function can be more cost-effective, especially at scale.

Wrapping Up

Lambda-lyth challenges the notion that each route in an API must be a separate Lambda function. By recognizing the appeal to tradition for what it is (a fallacy),we can embrace a more resource-efficient, maintainable, and scalable approach to building REST APIs on AWS.

Break the tradition that microservices require dozens or hundreds of Lambdas. Centralize routing, logging, and error handling in a single function. Simplify your CloudFormation/CDK stack. Grow seamlessly as you add more routes or complexity.

Next Steps

Try the Examples: Explore the examples (Node.js in-house, Node.js with Hono, Python with Lambda Powertools) to see how Lambda-lyth can be adapted. Look Out for Node.js APIGatewayRestResolver: AWS Lambda Powertools will eventually add this functionality, making the Node.js developer experience even more streamlined. Share Feedback: If you have questions or run into issues, open a GitHub issue or leave a comment on the blog. Collaboration helps refine the pattern!

Final Thoughts

Traditions can offer wisdom, but sometimes they also turn into anti-patterns—especially when technology evolves and new solutions arise. Lambda-lyth is about leveraging AWS in a modern, lean way: one Lambda to rule them all, with a well-structured codebase to keep your application maintainable and future-proof.

Remember: “We’ve always done it this way” isn’t a good enough reason to ignore a simpler, more powerful approach.

Useful Commands & Wrap-Up

GitHub Repository

You can find the complete source code and examples for the Lambda-lyth approach in the following GitHub repository:

Lambda-lyth Examples Repository

Feel free to clone the repository, explore the code, and try out the examples to see how the Lambda-lyth approach can be implemented in your own projects.

deploy all the stacks

npm run deploy

on your terminal search for outputs for

Outputs for TodosNodeApiStack:
TypeScriptApiUrl: https://qucskya5cg.execute-api.eu-west-1.amazonaws.com/dev/
TypeScriptApiEndpoint0AE0A5EC: https://qucskya5cg.execute-api.eu-west-1.amazonaws.com/dev/

Outputs for TodosPythonApiStack:
PythonApiUrl: https://khuneym1pe.execute-api.eu-west-1.amazonaws.com/dev/
PythonApiEndpointE96D1ECC: https://khuneym1pe.execute-api.eu-west-1.amazonaws.com/dev/

Outputs for NodeApiHonoStack:
HonoApiUrl: https://yy5p98do95.execute-api.eu-west-1.amazonaws.com/dev/
HonoApiEndpointA8719E91: https://yy5p98do95.execute-api.eu-west-1.amazonaws.com/dev/

use any api to test the lambda-lyth approach

# post a todo
curl -X POST https://qucskya5cg.execute-api.eu-west-1.amazonaws.com/dev/todos -d '{"title": "new todo", "description": "new todo description"}'

#output
# {
#   "id": "4a1aa888-89e8-4fc0-8993-4f179fad91b3",
#   "title": "todo 1",
#   "description": "todo 1 description",
#   "completed": false,
#   "createdAt": "2025-01-07T11:19:00.689Z",
#   "updatedAt": "2025-01-07T11:19:00.689Z"
# }

# get todo list
curl https://qucskya5cg.execute-api.eu-west-1.amazonaws.com/dev/todos

#output
# [
#   {
#     "completed": false,
#     "updatedAt": "2025-01-07T11:19:00.689Z",
#     "createdAt": "2025-01-07T11:19:00.689Z",
#     "description": "todo 1 description",
#     "id": "4a1aa888-89e8-4fc0-8993-4f179fad91b3",
#     "title": "todo 1"
#   }
# ]