Start with the product economics
The product needed a real backend for mobile and web clients, but it was deliberately small. Expected traffic did not justify paying for or operating an application server around the clock.
A conventional deployment would have introduced a fixed footprint before demand was known: continuously provisioned compute, runtime maintenance, capacity planning, scaling infrastructure, and responsibility for process health.
The architecture needed to be credible in production without pretending the product had enterprise-scale traffic.
Why serverless, and why AWS
Serverless aligned the operating model with the product. API operations could execute as isolated functions behind a managed HTTP boundary, while on-demand persistence and managed identity reduced the amount of infrastructure that needed to stay running or be maintained directly.
The decision was not that serverless is universally better. It was that usage-based services matched this product’s expected scale, team size, and tolerance for operational overhead.
Cost follows use
Compute and persistence could remain modest while activity remained modest, without provisioning an idle server for hypothetical demand.
A difficult managed capability
AWS offered livestreaming infrastructure the product could integrate instead of building a specialist media platform from scratch.
The system boundary
Serverless request path
API Gateway provides the shared HTTP boundary. TypeScript Lambda functions group backend behavior by capability. Cognito owns authentication and token issuance, while application services continue to enforce resource-level permissions.
DynamoDB uses a single-table model shaped around known access patterns. Conditional writes and transactions protect workflows requiring uniqueness or coordinated state changes. S3 keeps media transfer away from application compute through short-lived presigned operations.
The same API supports native and browser clients. Their interfaces and device responsibilities differ, but they do not carry separate versions of authentication, persistence, or backend rules.
Managed livestreaming
Livestreaming was the requirement that most strongly influenced the cloud choice. Building it internally would have meant owning stream ingestion, channel provisioning, broadcaster credentials, low-latency playback, lifecycle detection, scaling, and media delivery.
Amazon IVS provided those primitives as a managed service. The backend provisions channels and controls access to broadcast credentials, while lifecycle events allow application state to react to streams beginning and ending without treating a client device as the source of truth.
This was a speed-versus-control trade-off: greater AWS coupling in exchange for faster implementation, less specialist infrastructure, and lower operational ownership.
What the architecture costs
Managed does not mean automatic, and serverless does not mean there is no systems work.
What it avoids
An always-on server, custom identity infrastructure, direct media transfer through application compute, and a bespoke streaming stack.
What it introduces
Provider coupling, cold-start considerations, distributed observability, IAM review, access-pattern design, and explicit cross-service failure handling.
Infrastructure is represented through composable AWS SAM templates rather than console configuration. Routes, functions, authorizers, storage, event integrations, permissions, and environment parameters remain reviewable as code.
Serverless relocates the work
Instead of managing servers, the difficult decisions become function boundaries, access patterns, permissions, event handling, failure isolation, quotas, and the contracts connecting managed systems.
For this product, that was the right exchange. Modest expected traffic did not justify owning idle compute, while managed livestreaming removed a large specialist infrastructure problem from the critical path.