AWS Lambda Mastery: Handlers, Event Triggers & Concurrency

AWS Lambda is the industry benchmark for Function-as-a-Service (FaaS). Launched in 2014, Lambda lets you run code for virtually any type of application or backend service with zero administration. In this master class, we explore the internal anatomy of a production Lambda function, container reuse optimizations, event-source mappings, and concurrency management.

Anatomy of an AWS Lambda Function (Node.js)

Every Lambda function requires an exported Handler Method that accepts an event payload and a context runtime object:

// index.mjs - Production AWS Lambda Handler
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, PutCommand } from "@aws-sdk/lib-dynamodb";

// INITIALIZATION PHASE: Initialize clients OUTSIDE handler for container reuse!
const client = new DynamoDBClient({});
const docClient = DynamoDBDocumentClient.from(client);

export const handler = async (event, context) => {
    console.log("Processing Request ID:", context.awsRequestId);

    try {
        // Parse incoming HTTP request body from API Gateway
        const body = JSON.parse(event.body || "{}");
        
        // Save record into DynamoDB
        await docClient.send(new PutCommand({
            TableName: process.env.ORDERS_TABLE,
            Item: {
                orderId: context.awsRequestId,
                user: body.user,
                amount: body.amount,
                timestamp: new Date().toISOString()
            }
        }));

        return {
            statusCode: 201,
            headers: { "Content-Type": "application/json" },
            body: JSON.stringify({ message: "Order processed successfully!", orderId: context.awsRequestId })
        };
    } catch (error) {
        console.error("Lambda Error:", error);
        return {
            statusCode: 500,
            body: JSON.stringify({ error: "Internal Server Processing Error" })
        };
    }
};

Lambda Concurrency Models: Reserved vs Provisioned

Understanding concurrency is critical to preventing downstream database saturation and ensuring zero cold starts:

• Unreserved Concurrency: By default, an AWS account has a regional pool of 1,000 concurrent executions shared across all Lambda functions. If an unconstrained worker spins up 1,000 instances, it can throttle all other functions in your account!
• Reserved Concurrency: Guarantees that a critical function always has a dedicated slice of execution capacity (e.g., reserving 200 concurrency for Payment API), while simultaneously acting as a ceiling to prevent an unthrottled function from overwhelming downstream relational databases.
• Provisioned Concurrency: Pre-initializes a requested number of execution environments (microVMs, runtimes, and code) so that functions respond with double-digit millisecond latency with zero cold starts.

Synchronous vs Asynchronous vs Event-Source Mapping