Building a Production-Grade Serverless API on AWS: Architecture, Tradeoffs, and Lessons

Nick Gojaman — Wed, 24 Dec 2025 19:13:48 +0000

Most tutorials focus on building features. This project focused on operating a real backend system in production.

What is IntellPulse?

IntellPulse is a backend-first, API-only service that generates quantitative trading signals (BUY / HOLD / SELL) with explainability, quota enforcement, and safe deployments.
There is intentionally no UI. The goal was to design and ship a system that behaves like internal fintech infrastructure — not a demo app.
This project emphasizes:

End-to-end system design (request flow + deployment flow)
Security and access control (authentication, rate limiting)
Operational discipline (staging environments, digest-pinned deployments)
Production readiness (quota tracking, safe rollbacks)

This article walks through the architecture, key design decisions, and tradeoffs involved in building a production-grade serverless API on AWS — without overengineering.

Architecture Overview

IntellPulse is implemented as a serverless, container-based API with clear separation between runtime and deployment flows.
Request Flow (Runtime)

Clients access the API over HTTPS using an AWS Lambda Function URL
Requests are handled by a FastAPI application running inside a containerized Lambda function
Authentication and quota enforcement are applied before any signal logic executes
Usage and rate-limit state is stored in Amazon DynamoDB
The API returns structured JSON responses containing signals and explainability metadata

Deployment Flow (CI/CD)

Code changes trigger a CI/CD pipeline
A container image is built and pushed to Amazon ECR
The Lambda function is updated using a digest-pinned image reference (@sha256)
Deployments are promoted through staging → production environments

This design keeps the runtime path minimal and predictable, while allowing deployments to be performed safely without configuration drift or accidental rollbacks.

🧠 Key Design Decisions

1️⃣ Why Lambda Function URLs instead of API Gateway?

For this project, I intentionally used AWS Lambda Function URLs instead of Amazon API Gateway.
Rationale:

The goal was to expose a small, controlled API surface without introducing additional infrastructure overhead
Lambda Function URLs provide native HTTPS access and integrate cleanly with Lambda-based authentication logic
Advanced API Gateway features (custom domains, request mapping templates, usage plans) were not required for this use case

Tradeoff accepted:

Fewer built-in features (no native throttling UI, no API key management)
But: Simpler architecture, faster iteration, lower cost

What this shows: Understanding when to use lighter-weight AWS services vs. defaulting to heavier managed solutions.

2️⃣ Why container-based Lambda for FastAPI?

Rather than adapting FastAPI to a zip-based Lambda deployment, the service runs as a containerized Lambda function stored in Amazon ECR.
Why containers?

Full control over Python dependencies (no Lambda layer size limits)
Consistent execution environments (local dev = cloud production)
Easier iteration without Lambda packaging constraints

What this enables:

FastAPI runs naturally without framework-specific workarounds
Still benefits from Lambda's serverless execution model (auto-scaling, pay-per-request)

Alternative considered: Lambda Layers
Why rejected: Dependency conflicts and size limits made iteration slower

3️⃣ Why DynamoDB for rate limiting and quotas?

Rate limiting and daily usage quotas are enforced using Amazon DynamoDB rather than in-memory or middleware-based solutions.
Why DynamoDB?

Scales automatically with request volume
Predictable performance under load (single-digit millisecond latency)
Per-key usage tracking with TTL-based expiry (automatic cleanup)

Implementation approach:

Each API key has a DynamoDB item with requests_today and last_reset_timestamp
Quota checks happen before signal logic executes
TTL automatically deletes expired quota records

What this shows: Stateful, durable, horizontally scalable quota enforcement that works at any scale.

4️⃣ Why digest-pinned deployments (@sha256)?

CI/CD deployments update Lambda functions using digest-pinned container images (@sha256:abc123...) rather than mutable tags like latest.
Why this matters:

Each deployment is deterministic (exact image version is known)
Rollbacks reference known artifacts (not "whatever latest points to now")
Production never pulls unintended versions (no tag drift)

Example:
bash# ❌ Bad: Mutable tag
aws lambda update-function-code --image-uri 123456789.dkr.ecr.us-east-1.amazonaws.com/intellpulse:latest

✅ Good: Digest-pinned

aws lambda update-function-code --image-uri 123456789.dkr.ecr.us-east-1.amazonaws.com/intellpulse@sha256:abc123...
Tradeoff: Adds CI/CD complexity (pipeline must resolve digests)
Benefit: Significantly improves deployment safety and traceability
What this shows: Senior-level deployment discipline and understanding of immutable infrastructure.

5️⃣ Why separate staging and production environments?

Even for a relatively small backend service, separate staging and production environments were maintained.
Why staging matters:

Validate CI/CD changes before they reach production
Test deployment logic safely (digest resolution, rollback procedures)
Build confidence in changes before promotion

Implementation:

Staging uses its own Lambda function, DynamoDB table, and ECR repository
CI/CD pipeline deploys to staging first, then requires manual approval for production
Both environments use the same codebase but different AWS accounts (or separate regions)

What this shows: Operational discipline that mirrors patterns used in larger systems and scales beyond single projects.

⚖️ Tradeoffs and Lessons Learned

Building IntellPulse reinforced the importance of intentional tradeoffs when designing production systems.
Backend-Only Approach
Tradeoff: No visual demo for non-technical users
Benefit: Full focus on correctness, security, and operational discipline
Lesson: Acceptable tradeoff when the target audience is API consumers, not end users
Lambda Function URLs vs API Gateway
Tradeoff: Fewer built-in features (no native throttling, no usage plans)
Benefit: Simpler architecture, faster iteration
Lesson: Understand service boundaries and avoid defaulting to heavier components when they're not required
Digest-Pinned Deployments
Tradeoff: Added CI/CD complexity upfront
Benefit: Eliminated risk of accidental production regressions
Lesson: Safety mechanisms pay off even at small scale

🚀 What's Next?

If I were extending this system further, the next improvements would focus on operational maturity and developer ergonomics, not additional features.

Planned enhancements:

Infrastructure as Code (Terraform or AWS CDK) — eliminate manual AWS Console changes
Structured observability (CloudWatch metrics, X-Ray tracing) — understand system behavior in production
Lightweight UI — internal dashboard for monitoring usage and quotas
- Update: Built an interactive demo UI at https://intellpulse-signals-insight.lovable.app
Additional signal strategies — expand beyond simple BUY/HOLD/SELL logic
Historical query support — allow clients to retrieve past signals

Importantly: These enhancements build on a stable foundation rather than compensating for architectural gaps.

📦 Source Code

The full implementation, including the FastAPI service, Lambda container setup, DynamoDB quota logic, and CI/CD pipeline, is available here:
GitHub: https://github.com/Gojaman/intellpulse

💡 Key Takeaways for Builders

Production-grade doesn't mean overengineered — choose the simplest solution that meets requirements
Deployment safety scales down — digest-pinned deploys and staging environments aren't just for "big systems"
Understand your constraints — Lambda Function URLs vs API Gateway isn't a "one is better" decision; it's context-dependent
Build for operators, not just users — quota enforcement, rollback procedures, and observability matter from day one

Want to discuss serverless architecture or trading system design? Connect with me:
📘 LinkedIn | 💻 GitHub | 🐦 X

DEV Community: Nick Gojaman