Serverless backend development on AWS

When a serverless back end is the right choice

A serverless back end has no server that is always on. The code lives as functions on AWS Lambda and runs only when there is a request, a queue message or a task that is due. As requests grow, AWS starts new copies of the same function; the operating system, capacity and load distribution are AWS’s responsibility. Our job is to set up the functions, the queues between them, the permissions and the monitoring correctly.

Where AWS serverless fits well

You are building the back end of a mobile app, and traffic rises and falls with campaigns, the time of day or the season
Part of the work can happen without making the user wait: notifications, emails, exports, webhooks from outside services
You do not want to set aside a team to update and watch servers
Your company already uses AWS, or you want the new system to run in your AWS account

Where we would suggest another route

The app depends on connections that stay open: Hippotenus’s Socket.IO messaging runs on a long-running server
Load is high and steady all day: a fixed-price server with Docker and Coolify can be more predictable
The data has to sit on a specific server of your choosing: Hippotenus and Logaritim run on our own server with Docker and Coolify
A long calculation has to happen inside a single request: a Lambda invocation has a limited running time

	AWS Lambda (with SAM)	Your own server (with Docker and Coolify)
With no traffic	Functions do not run; Lambda is billed by the number of requests and the running time	The server is always on and its price does not change
Sudden peaks	AWS starts new copies; the limit is set by the account’s concurrency quota and by the database	Limited by the server’s capacity; growing it takes planning ahead
Long jobs and open connections	The work is split into a queue or a separate function	A long-running process carries it directly
Maintenance	The operating system is on AWS; we upgrade the Node.js version in the template	Operating-system patches, disks and backups are on you or your maintenance team
Our example	Rigel, LydiaVault	Hippotenus, Logaritim, pepechura.com

Which AWS service does what in Rigel and LydiaVault

The back ends of the two mobile apps we built for Kata Technology run serverless on AWS. Both use MongoDB as their database; the other parts are AWS services:

Lambda

API endpoints, webhooks, queue workers and scheduled tasks. In Rigel, heavy jobs such as merging videos run in separate functions with an ffmpeg layer and more memory.

API Gateway

The front door of the REST API. A Lambda authorizer checks the user’s JWT before a request reaches a function. In Rigel and LydiaVault; Rigel’s API is served from its own domain.

SQS

The notification and email sending queues in Rigel; behind each queue is a dead-letter queue (DLQ) that collects the messages that could not be processed.

S3

Uploaded photos and generated videos in Rigel, spending receipts in LydiaVault. Photos and receipts are opened through time-limited signed links; Rigel’s videos are served through CloudFront.

Secrets Manager

Rigel reads its OpenAI key, its JWT signing key and its Firebase service account from here; the value is kept in memory for as long as the function copy stays up.

SES

Sign-up verification codes and campaign emails in Rigel, password-reset emails in LydiaVault.

CloudWatch and X-Ray

Logs, metrics derived from logs, alarms and dashboards. X-Ray traces function calls in both apps.

DynamoDB

A cache for Rigel’s explore feed; DynamoDB deletes the entries by itself once they expire.

On Lambda, every function copy opens its own database connection. So we keep the MongoDB connection outside the request, at module level: later requests that reach the same copy reuse it, and the connection pool is kept small on purpose. In Rigel the connection is pinged before use; if it has dropped, it is closed and a new one is opened.

Work that does not keep the user waiting: queues, retries, dead-letter queues

Notification and email campaigns prepared in Rigel’s admin panel are not sent inside the panel’s request. Sending is split across functions with SQS queues between them:

A campaign is scheduled in the panel

A scheduled function writes the sends that are due to SQS

A worker function processes the messages one by one

A message that fails goes back to the queue and is retried

A message that runs out of retries waits in the dead-letter queue for review

How notifications and emails are sent in Rigel

Each recipient’s send status is kept in the database, and the worker only picks recipients that are still queued; a retried message skips recipients already marked as sent.
Users who unsubscribed are skipped in campaign emails; the unsubscribe link goes to a public endpoint.
No function waits for AI video generation: Rigel hands the job to the provider, and the provider calls Rigel’s webhook when the job is done. Subscription events from RevenueCat also land on their own webhook function.
Long jobs such as data exports in the admin panel are handed off by the function that receives the request to another function through an asynchronous call; the panel gets a job ID at once and asks for the result later.

Infrastructure as code: AWS SAM and monitoring

Rigel’s functions, API, queues and dead-letter queues, scheduled tasks, DynamoDB table, alarms, dashboards and custom domain are all defined in a single AWS SAM template. In LydiaVault the functions, the API and the authorizer are in the template the same way. The template lives in the same repository as the code, so the commit history shows when and why a queue or an alarm was added.

Topic	How it works in Rigel	What it gives you
Environments	Separate staging and production stacks from the same template; per-environment settings in the samconfig file	Both environments are built from one definition; alarms and dashboards are switched on only in production through conditions
Packaging	sam build bundles each function separately and minified with esbuild	Each function carries only its own code
Release	sam deploy shows the CloudFormation change set and asks for approval before applying it	What will be added, changed or deleted is visible in advance
Local development	With sam local the API can run on a developer’s machine	A change can be tried before it goes to AWS
Checks	On every push and pull request to the main and develop branches, GitHub Actions runs lint, the type check and the unit tests	Code that does not compile or breaks a test shows up early

Monitoring is part of the template too. Rigel writes its logs as structured JSON; CloudWatch metric filters turn particular log lines, such as failed video generations and RevenueCat payment errors, into metrics. A metric that crosses its threshold triggers an alarm, and the alarm goes through SNS to a Lambda function and on to Slack. Error-level log lines from critical functions are also forwarded to Slack. In Rigel, X-Ray also brings outgoing HTTP calls to outside services into the trace.

How an AWS serverless project runs

01
Free scoping call
30 min
We talk about which work has to happen at once and which can run in the background, and about where your AWS account stands today.
02
Written scope and quote
We write down the functions, queues, scheduled tasks, data and file storage and monitoring, together with the acceptance criteria.
03
Weekly releases
Every week a working version goes out to the staging environment; you can try the endpoints from the app itself or from an API client.
04
Testing and release
A senior QA tests the version on staging before it moves to production; on the way to production the change set is reviewed and approved.
05
The 30 days after launch
30 days
We fix the bugs found in this period free of charge; after that you can carry on with monthly maintenance.

Timelines and budget ranges are on our service pages and the pricing page; this page contains no figures that differ from them.

Questions about AWS serverless

Will I be locked in to AWS?

Partly, and we say so plainly from the start. The business rules sit in ordinary TypeScript code and the database is MongoDB; neither is tied to AWS. SQS, SES, Secrets Manager and the SAM template are AWS-specific, so moving elsewhere means setting up their equivalents. The S3 interface, on the other hand, is a widespread standard: Hippotenus keeps its files in another S3-compatible storage service using the same AWS SDK.

Are cold starts a problem?

There is a short delay when a function copy starts for the first time. To keep it small we bundle each function separately and minified with esbuild, and we keep the database connection, and in Rigel the values read from Secrets Manager, in memory for as long as the copy stays up. That way only the first request to reach a copy pays the cost. If every request in your case is very sensitive to latency, we look at this separately in the scoping call.

Do you use Kubernetes, ECS or RDS?

Not in Rigel or LydiaVault: both run on Lambda without managing servers or containers, and their databases are MongoDB. In projects that need an always-running container, as in Hippotenus and Logaritim, we use our own server with Docker and Coolify.

Can you work in our own AWS account?

Yes. Because the infrastructure is defined in the template, the same template can be deployed to your account; we set up staging and production as separate stacks. Resources set up outside the template, such as the S3 bucket and the domain certificate, are passed in as parameters, so it stays clear where each resource comes from.

What do I keep when the project ends?

A perpetual licence to use the software, and documentation. If you want the source code transferred to you together with the SAM template, that comes at an extra fee, written separately in the quote.

Serverless backend development on AWS

What we have built with it

Rigel

LydiaVault