Case study
Caching and serverless: a faster, more scalable architecture with DynamoDB and NestJS
schedule3 min
calendar_today21 October 2025
syncCaricamento...
Introduction
We introduced a substantial caching layer to save time, improve performance, optimise costs and make it possible to run the system efficiently in serverless mode.
A seemingly simple change, but one that radically changed how one of our architectures behaves under load.
The context
One of our clients — a retail business with a digital ecosystem built entirely on AWS Lambda, API Gateway and NestJS — kept running into the same problem:
the application was scalable in theory, but in practice it showed high latency and rising costs, despite the serverless structure.
Every request, even for identical data, had to restart the whole chain:
Lambda → query to Aurora Serverless → serialisation → response.
An elegant model, but not an efficient one when the same information was being requested thousands of times a day.
The approach
The first step was to measure: using AWS X-Ray and CloudWatch Insights we traced where the milliseconds were being lost.
The answer was clear: too many round trips to the database, no persistence of temporary data.
In a serverless environment, where each function lives only for a few moments, volatile memory is not a solution.
We needed an external layer that was fast, cheap and scalable.
So we introduced a distributed caching layer on DynamoDB, designed as a key-value store with automatic TTL (time-to-live).
The system keeps the results of the most expensive calls for a few minutes, allowing subsequent Lambdas to respond in milliseconds without querying Aurora.
The final architecture
The request flow has now been completely redesigned:
- API Gateway receives the request.
- Lambda (NestJS) checks the caching layer on DynamoDB.
- If the data is available, it responds immediately.
- Otherwise, it queries Aurora Serverless, updates the cache and returns the response.
All of this is orchestrated transparently for the end user and fully automated through GitHub Actions and AWS CDK, to guarantee consistent versioning and deployment.
The results
The impact was immediate:
- Average latency reduced by over 85%.
- Database queries reduced by 90%.
- Overall AWS costs down by about 40%.
- No impact on scalability; on the contrary, the distributed cache made the Lambdas even more stateless and performant.
In practice, the application stopped “starting from scratch” on every call.
And the serverless system, elegant on paper, finally became efficient in reality.
An important lesson
This case reminded us of a truth that people working in the cloud often underestimate:
Serverless does not mean giving up on optimisation.
It means optimising differently.
A cache is not a luxury or an add-on, but a pillar of any truly scalable architecture.
In the serverless world, where every function is ephemeral, caching is what provides continuity.
Stack involved
- AWS Lambda (Node.js 20)
- NestJS as the application framework
- AWS DynamoDB as the caching layer with TTL
- Aurora Serverless v2 (PostgreSQL) as the main storage
- AWS X-Ray and CloudWatch Insights for monitoring
- GitHub Actions + CDK for the deploy pipeline
Conclusion
Adding a caching system was not just a technical improvement:
it was an architectural transformation that made the entire serverless ecosystem sustainable.
At Shellonback, we believe innovation is not only about “what you use”, but about how you make the technologies work together.
And this project shows it perfectly.