Poja is built on top of AWS Lambda and AWS SAM (Serverless Application Model). Understanding this architecture helps you reason about performance, scaling, and the constraints your application operates within.
Infrastructure stack
When you deploy a Poja application, the following AWS services are provisioned and managed on your behalf:
Service | Role |
|---|---|
AWS Lambda + SnapStart | Runs your Spring Boot app |
AWS API Gateway | Exposes your HTTP endpoints to the internet |
AWS SQS | Powers async queues and event workers |
AWS EventBridge | Routes events from producers to consumers |
AWS S3 | File storage and build artifact uploads |
AWS SES | Email sending via the |
You never configure any of these directly — Poja handles all provisioning through its own API.
No cold starts with Lambda SnapStart
Instead of initializing your application from scratch on every cold start, SnapStart moves the initialization work to deployment time:
When Poja deploys your app, Lambda initializes the function fully — JVM startup, class loading, Spring context initialization — all of it runs once.
Lambda takes an encrypted snapshot of the fully initialized memory and disk state of that execution environment.
The snapshot is cached. When Lambda needs a new execution environment (due to scaling or a cold start), it restores from the snapshot instead of initializing from scratch.
The result: your application responds fast on every request, including the first one after a period of inactivity.