Tibica: Serverless Latency Optimization

A Lambda cold start happens when AWS needs to initialize a new execution environment for a function that hasn't run recently. This initialization adds latency — typically between 200ms and 2 seconds depending on the runtime and function size. Cold starts are most noticeable in applications where users trigger multiple Lambda functions in sequence, as the delays compound across each step of the workflow.

Lambda cold starts were adding nearly two seconds to each affected request in Tibica's case. By routing simple GET, PUT, and POST operations directly from API Gateway to DynamoDB via VTL, those requests no longer trigger a Lambda function at all. No function initialization means no cold start penalty. For operations that don't need business logic, this is a faster and more cost-efficient path.

VTL (Velocity Template Language) is a templating language that API Gateway uses to transform requests and responses. When integrated with DynamoDB, it allows API Gateway to construct database queries directly — without a Lambda function in the middle. It's a native AWS capability that's well-suited for simple CRUD operations where the request just needs to be mapped to a database action.

No. Direct API Gateway to DynamoDB integration is appropriate for stateless, simple operations: reads, writes, and updates that follow a predictable pattern and don't require conditional logic, external API calls, or data transformation. Functions with business logic, authorization checks, or complex processing still belong in Lambda. The AWS X-Ray analysis identified which of Tibica's functions fit the simpler profile.

AWS X-Ray is the right tool for this. It traces requests end-to-end across services, showing exactly where time is spent in each part of a workflow. In Tibica's case, X-Ray made it clear that the majority of requests were simple GET operations with no logic that required Lambda. Without that data, the optimization opportunity would have been much harder to identify.

Tibica's Lambda compute costs dropped by 50% after the migration. The savings came from two places: fewer Lambda invocations overall, since simple operations no longer triggered functions, and shorter execution times for the Lambda functions that remained. DynamoDB request costs did increase slightly, but the net result was a 50% reduction in total compute spend for these workflows.

This was the second engagement Perfsys completed for Tibica. The first involved migrating Lambda functions from x86_64 to the arm64 architecture, which delivered a 17% improvement in Lambda response times and 20% cost savings. The two optimizations targeted different layers: architecture choice in the first case, integration pattern in the second. Together they significantly improved the platform's overall performance and cost profile. You can read about the architecture migration in the AWS Performance Optimization case study.